Jesse Keating wrote: > On Thu, 26 Jul 2007 16:32:30 -0500 > Dan Yocum <yocum@xxxxxxxx> wrote: > >> It's stable, widely tested, widely deployed, and >> it's being actively developed and maintained (which is more than can >> be said of some other filesystems that remain in the default list). >> It's in the kernel, it shouldn't be "hidden" in the depths of >> anaconda anymore. > > How's the SELinux support these days? Should be fine. Do you know of any outstanding bugs? (the selinux debacle for FC6 was my fault... I took the sgi guys' word that a new mkfs option was well tested & optimal for selinux; turns out that wasn't quite right. Bug was resolved pretty quickly after working with the sgi xfs team, though). > And why can't I boot from xfs > yet? have you tried lately? It's always been fine on Suse... Based on the ext3 vs. grub corruption problem I sorted out with pjones for RHEL, it was because the way anaconda invoked grub, grub was doing STUPID things like writing to the underlying block device *while the filesystem was mounted* This occasionally wreaked havoc with ext3 and may have been the root cause for xfs too. "sync sync sync sync write to the bdev" is not a good plan for grub for ANY fs. The only other limitation on xfs & grub is that since the xfs superblock lives in the first sector, you can't install grub to an xfs *partition*. MBR works fine though. The remaining issue may be xfs+4kstacks+complicated/deep IO stacks on x86. Honestly I've never much liked 4kstacks... layered filesystems coming down the pipe (ecryptfs, unionfs) may well have trouble too. I'd prefer to see the stack size boot-time selectable, maybe - or perhaps disallow xfs (or issue a stern warning) on x86 boxes? (x86_64 & ia64, with sane stack size, work fine in this regard). -Eric -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
