[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: please enable XFS in anaconda

Jesse Keating wrote:
> On Thu, 26 Jul 2007 16:32:30 -0500
> Dan Yocum <yocum fnal gov> 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).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]