... The copy of the message I sent which I received was incomplete. I'm resending it.
On Sat, 2002-03-23 at 07:26, Ed Wilts wrote: > OE mangled your message - it came through entirely as an attachment so it's > a little more awkward for me to reply, so I'm leaving your message intact at > the bottom. Might just be OE, but it's only a couple of people on the list > that this does it to me with... We're probably all using Evolution with PGP. ;) > Looking at the e-mail on my imap server, it > came through as a MIME-formatted message. mutt complains about the pgp > signature. Oh well... I've noticed that this happens with messages I send to mailing lists. I don't know why, though. I'm guessing the mailing list modifies the message body, but I don't know why it would modify the message body inside the MIME boundaries. > 1. I agree that there is nothing wrong with offering CVS access. However, > the FAQ clearly suggests that if you want to install XFS, "the best way to > do this is to checkout the SGI XFS kernel from their CVS tree". Always the latest code :) The binary packages they offer follow Red Hat's kernel releases, and not the current kernel releases. SGI's testing may indicate the the latest kernel is better than Red Hat's current production kernel by some measure. I don't know, but it looks like Red Hat will be shipping 2.4.18+ with their next Linux distribution release. > 2. "[they offer] an ISO which you can use to install Red Hat Linux on XFS > filesystems." Let's be blunt here. If the ISO comes from SGI, it's not Red > Hat Linux. That's correct. I believe, however, that the installer ISO contains only the anaconda installer, the kernel rpms, the XFS command rpms, and other packages specifically required by the installer. Everything else comes from the standard Red Hat CD's. > It's some distribution that may be based on Red Hat Linux > underneath, but it may or may not have critical patches applied that fix > security holes, fix bugs, enhance stability, whatever. It looks like SGI > may start with Red Hat kernel source rpms, so that's a good thing, but if a > new patch comes out for the kernel, you may be waiting an extra day or two > for it to make it to the XFS project. That's probably true. Do you expose your fileserver to untrusted users? Security is risk management. One should not disregard a product because of security concerns, unless the risks outweigh the benefits. In the case of the kernel, your risks are very likely going to be limited to local users in the case of privilege elevation, or DOS attacks from remote users. Those are risks that can normally be managed if you want ACL's, which provide a very functional enhancement to the security of the system. > 3. This is a Red Hat list and I would assume that the average person on > this list is a Red Hat user. Replacing Red Hat's kernel with someone else's > is not something the average person should do lightly, and in fact, I would > suspect that the average person doesn't know how to even do this and > understand the risks involved. Yes, but the users who want ACL's probably do. Understanding ACL's and how their benefits from an administrative standpoint is probably more complex that understanding a kernel install. "rpm -ivh kernel..." > 4. I quoted the FAQ when I said that there was no installer for 7.2. > Obviously the FAQ is out of date. You're right. Looks like an oversight. > 5. When I said limited support backup tools, I knew that xfsdump existed. > How about tar? Will it backup and restore ACLs? What about commercial > backup utilities like netbackup? That's what I meant about limited support. > Sure, you can use the ONE utility that's provided, but you may be rewriting > your existing backup/restore scripts or be forced to scrap the commercial > tool you're already running. Tar doesn't back up extended information from any filesystem, on any platform that I'm aware of. Every filesystem for every platform that I'm aware of has its own "dump" utility. The native dump tool is normally used by commercial systems. > 6. You're welcome to disagree as to whether or not it's ready for the > average file server. Perhaps what you consider average is different from > mine. If you want a journalling file system that's not supported by your OS > supplier (Red Hat) If your vendor doesn't provide the capabilities you need, you're going to have to get something that they don't support. That's true of any vendor for any product. > , has limited support for enterprise backup tools, Spend more time in the enterprise :) Dump is where it's at. > forces > you to get updates from two different vendors, go for it. I *ove that Red Hat provides so much from one vendor, but spend some time using any other product. It doesn't matter who your vendor is, eventually you will need something that they don't provide. Would you disregard commercial backup solutions, because Red Hat doesn't support them? Would you ignore commercial databases because they aren't part of the distribution? > I'm not saying > XFS is bad or that it isn't right for you. If I have a colleague who wants > to install a file server at home, I'm sure not going to recommend an XFS > file system at this time (he probably doesn't need ACL support either). If Well, yeah... If he doesn't need ACL's, then there's no reason to use SGI's kernel. I don't mean to say that everyone should. However, it's a good solution for anyone who *does* need ACL support. > I want to run a production big-business file server at work that demands ACL > support, I personally wouln't run it there either in its current state, and > that's where we started this thread. Would you believe a vendor that said > that the software was stable? In my opinion, XFS just hasn't been out > long enough on Linux to prove long-term stability and vendor committment. You're free to make your own decisions, of course. My recommendation is for XFS. It's been stable and available (1.0+) for nearly a year, and in all that time, I've never heard from a user with problems. Now Reiserfs.... That's a different story.
signature.asc
Description: This is a digitally signed message part
