4:32 p.m.
Hi,
It's been many years since I, and others, have pushed Marcelo and Linus
to include XFS in the kernel. And we *have* been able to install using
XFS as the default filesystem by passing the command line option 'linux
xfs' (see: http://www.fedorafaq.org/#reiserjfs) when starting the
install, but can you please enable XFS as a default FS option during the
formating section so we don't have to remember to pass this option when
booting?
Here at Fermilab we've got nearly a petabyte (or more!) of spinning disk
with XFS filesystems. 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.
Thanks,
Dan
--
Dan Yocum
Fermilab 630.840.6509
yocum(a)fnal.gov, http://fermigrid.fnal.gov
Fermilab. Just zeros and ones.
6:07 p.m.
On Thu, 26 Jul 2007 16:32:30 -0500
Dan Yocum <yocum(a)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? And why can't I boot from xfs
yet?
--
Jesse Keating
Release Engineer: Fedora
6:25 p.m.
On 7/26/2007 4:07 PM, Jesse Keating wrote:
On Thu, 26 Jul 2007 16:32:30 -0500
Dan Yocum <yocum(a)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? And why can't I boot from xfs
yet?
Back in the old Red Hat Linux and FC2-4 days when I had more time, I
seem to remember that Grub fully supported XFS. I could make all the
filesystems XFS and I could boot just fine from them. Nowadays, I have
less time, or I'm lazy, and just accept the Anaconda ext3 defaults for
the system partitions. I still store all the important user data under
XFS, though. I haven't lost a byte to XFS yet.
Can't comment on SELinux, don't use it :-) :-)
I agree with Dan.
7:52 a.m.
David Chambers wrote:
Can't comment on SELinux, don't use it :-) :-)
It doesn't matter whether you use it or not. SELinux support is
important to this project and filesystem is a critical piece. If anyone
is volunteering to support whatever features Fedora needs, test it and
keep it updated, that's when XFS can be considered for being available
for default.
I am not particular fond of the current solution either. I would prefer
it to be completed supported or dropped.
Rahul
9:18 a.m.
Rahul Sundaram wrote:
David Chambers wrote:
> Can't comment on SELinux, don't use it :-) :-)
It doesn't matter whether you use it or not. SELinux support is
important to this project and filesystem is a critical piece. If anyone
is volunteering to support whatever features Fedora needs, test it and
keep it updated, that's when XFS can be considered for being available
for default.
I'm already getting xfs bugs & xfsprogs bugs from fedora - some I fix,
some I pass on to sgi, some are still unfixed - IOW, about like any
other fedora subsystem. ;)
I'd be happy to continue to look after xfs & userspace as well as I can
(given various time constraints) for fedora, and I'm sure the sgi guys
will offer backup support as they have been already.
-Eric
9:51 a.m.
Eric Sandeen wrote:
Rahul Sundaram wrote:
> David Chambers wrote:
>
>> Can't comment on SELinux, don't use it :-) :-)
> It doesn't matter whether you use it or not. SELinux support is
> important to this project and filesystem is a critical piece. If anyone
> is volunteering to support whatever features Fedora needs, test it and
> keep it updated, that's when XFS can be considered for being available
> for default.
I'm already getting xfs bugs & xfsprogs bugs from fedora - some I fix,
some I pass on to sgi, some are still unfixed - IOW, about like any
other fedora subsystem. ;)
I'd be happy to continue to look after xfs & userspace as well as I can
(given various time constraints) for fedora, and I'm sure the sgi guys
will offer backup support as they have been already.
Excellent!
David - Since Eric has been kind enough to step forward and fill this
role, can we expect to see XFS in the next test release, then? I would
assume it would be too late to get it into test1...
Thanks,
Dan
--
Dan Yocum
Fermilab 630.840.6509
yocum(a)fnal.gov, http://fermigrid.fnal.gov
Fermilab. Just zeros and ones.
9:57 a.m.
On Thu, 02 Aug 2007 09:51:14 -0500
Dan Yocum <yocum(a)fnal.gov> wrote:
David - Since Eric has been kind enough to step forward and fill this
role, can we expect to see XFS in the next test release, then? I
would assume it would be too late to get it into test1...
Well, xfs is there already if you pass the 'xfs' flag at boot time.
More people testing xfs in more scenarios would be helpful.
--
Jesse Keating
Release Engineer: Fedora
10:06 a.m.
Jesse Keating wrote:
On Thu, 02 Aug 2007 09:51:14 -0500
Dan Yocum <yocum(a)fnal.gov> wrote:
> David - Since Eric has been kind enough to step forward and fill this
> role, can we expect to see XFS in the next test release, then? I
> would assume it would be too late to get it into test1...
Well, xfs is there already if you pass the 'xfs' flag at boot time.
More people testing xfs in more scenarios would be helpful.
Betcha we'd get more testing in more scenarios if we didn't require the
flag though... :)
--
Jarod Wilson
jwilson(a)redhat.com
10:31 a.m.
On Thu, 02 Aug 2007 11:06:56 -0400
Jarod Wilson <jwilson(a)redhat.com> wrote:
Betcha we'd get more testing in more scenarios if we didn't
require
the flag though... :)
Heh, sure. Still need to do that test to see if you can /boot from it
successfully.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
10:36 a.m.
On Thu, 2 Aug 2007 11:31:06 -0400
Jesse Keating <jkeating(a)redhat.com> wrote:
On Thu, 02 Aug 2007 11:06:56 -0400
Jarod Wilson <jwilson(a)redhat.com> wrote:
> Betcha we'd get more testing in more scenarios if we didn't require
> the flag though... :)
Heh, sure. Still need to do that test to see if you can /boot from it
successfully.
Rather than removing the flag now, how about a boot menu choice that passes the xfs
parameter? Not much different than requiring the parameter, but I guess the main point is
to explain on the boot screen what users need to do to enable installation to XFS. We
make it easier for people to test XFS and don't remove the flag from anaconda right
away.
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat / Westford, MA
2:20 p.m.
Jesse Keating wrote:
On Thu, 02 Aug 2007 11:06:56 -0400
Jarod Wilson <jwilson(a)redhat.com> wrote:
> Betcha we'd get more testing in more scenarios if we didn't require
> the flag though... :)
Heh, sure. Still need to do that test to see if you can /boot from it
successfully.
# mount | grep xfs
/dev/mapper/VolGroup00-LogVol00 on / type xfs (rw)
/dev/sda1 on /boot type xfs (rw)
Works quite nicely, thank you. :)
Nb: there are still two bugs related to getting that working, the first
being bug 250815 that I just filed, the second being a grub-install bug
that Eric is about to file.
--
Jarod Wilson
jwilson(a)redhat.com
1:46 a.m.
On Thu, 2007-08-02 at 10:57 -0400, Jesse Keating wrote:
Well, xfs is there already if you pass the 'xfs' flag at boot
time.
More people testing xfs in more scenarios would be helpful.
Is XFS ever going to get the ability to resize partitions smaller? Last
I tried it, it didn't. This is a showstopper for me, the utility of LVM
is greatly reduced if you can't size some volumes down to make room for
others...
9:21 a.m.
Callum Lerwick wrote:
On Thu, 2007-08-02 at 10:57 -0400, Jesse Keating wrote:
> Well, xfs is there already if you pass the 'xfs' flag at boot time.
> More people testing xfs in more scenarios would be helpful.
Is XFS ever going to get the ability to resize partitions smaller? Last
I tried it, it didn't. This is a showstopper for me, the utility of LVM
is greatly reduced if you can't size some volumes down to make room for
others...
There have been some 3rd-party patches (from Ruben Porras) floated on
the list lately, so there has been a little activity in this regard.
It's highly unlikely that it'd be available in the F8 timeframe though.
-Eric
9:05 p.m.
Jesse Keating wrote:
On Thu, 26 Jul 2007 16:32:30 -0500
Dan Yocum <yocum(a)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).
-Eric
9:15 p.m.
On Thu, 26 Jul 2007 21:05:15 -0500
Eric Sandeen <esandeen(a)redhat.com> wrote:
have you tried lately? It's always been fine on Suse...
Anaconda currently refuses to allow it. I was curious if the technical
reason has been fixed yet or not.
--
Jesse Keating
Release Engineer: Fedora
9:30 p.m.
Jesse Keating wrote:
On Thu, 26 Jul 2007 21:05:15 -0500
Eric Sandeen <esandeen(a)redhat.com> wrote:
> have you tried lately? It's always been fine on Suse...
Anaconda currently refuses to allow it. I was curious if the technical
reason has been fixed yet or not.
I'm not sure the root cause was ever quite sorted for xfs, but after
what I found with ext3, I'm more than willing to blame generic grub
problems. :)
Hmm wonder how hard it is to spin up an anaconda that allows it, for
testing...
-Eric
9:46 p.m.
Eric Sandeen wrote:
Jesse Keating wrote:
> On Thu, 26 Jul 2007 21:05:15 -0500
> Eric Sandeen <esandeen(a)redhat.com> wrote:
>
>> have you tried lately? It's always been fine on Suse...
> Anaconda currently refuses to allow it. I was curious if the technical
> reason has been fixed yet or not.
I'm not sure the root cause was ever quite sorted for xfs, but after
what I found with ext3, I'm more than willing to blame generic grub
problems. :)
Hmm wonder how hard it is to spin up an anaconda that allows it, for
testing...
Perhaps not hard for the non-livecd-install case. But as the livecd installer
currently works by copying an ext3 image file, instead of a format and
file-level copy, that will be a bit more work. Though in a discussion about
optimizing that process, Jeremy Katz did mention he might be looking into
implementing that, as an improvement for the case when /usr is on a separate
partition. Which would also be what would be needed for the non-ext3 (xfs) case.
-dmc
9:51 p.m.
On Thu, 26 Jul 2007 21:30:52 -0500
Eric Sandeen <esandeen(a)redhat.com> wrote:
Hmm wonder how hard it is to spin up an anaconda that allows it, for
testing...
Wouldn't be hard at all. Just find the python file that balks on
xfs /boot and modify it, then include it in either RHUpdates/ on an NFS
tree, or an updates.img that is loaded at boot time. If you don't get
around to it, I may do just that next week after Test1 is baked.
--
Jesse Keating
Release Engineer: Fedora
10:01 p.m.
On Thu, 26 Jul 2007 22:51:40 -0400
Jesse Keating <jkeating(a)redhat.com> wrote:
Wouldn't be hard at all. Just find the python file that balks
on
xfs /boot and modify it, then include it in either RHUpdates/ on an
NFS tree, or an updates.img that is loaded at boot time. If you
don't get around to it, I may do just that next week after Test1 is
baked.
In fact it's in partitions.py, round like 1000. Easy enough to strip
out for testing.
--
Jesse Keating
Release Engineer: Fedora
10:20 p.m.
Jesse Keating wrote:
On Thu, 26 Jul 2007 22:51:40 -0400
Jesse Keating <jkeating(a)redhat.com> wrote:
> Wouldn't be hard at all. Just find the python file that balks on
> xfs /boot and modify it, then include it in either RHUpdates/ on an
> NFS tree, or an updates.img that is loaded at boot time. If you
> don't get around to it, I may do just that next week after Test1 is
> baked.
In fact it's in partitions.py, round like 1000. Easy enough to strip
out for testing.
Well if I can make time I'd be happy to help investigate. I'm out 'til
next Tuesday, I'll catch up then & see if there's any news. :)
Thanks guys,
-Eric
8:53 a.m.
Eric Sandeen wrote:
Jesse Keating wrote:
> On Thu, 26 Jul 2007 16:32:30 -0500
> Dan Yocum <yocum(a)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...
And I had been booting from XFS since FC3 or so, but after experiencing
the problem described by Eric, I moved to ext3 for my /boot partition.
Dan
--
Dan Yocum
Fermilab 630.840.6509
yocum(a)fnal.gov, http://fermigrid.fnal.gov
Fermilab. Just zeros and ones.
11:23 a.m.
Eric Sandeen wrote:
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).
I can confirm that xfs on 4KSTACKS over lvm is still a problem.
Basic functionality is fine, but I can't make it through all of xfsqa
w/o a stack overflow. Even just mounting with -o quota gets us pretty
close to the edge:
mount used greatest stack depth: 180 bytes left
I'll look at some of the bigger offenders if I have any spare time in
the evenings. It's the callchains, too though, not just the individual
functions that come into play.
0x0001b719 xfs_bmapi [xfs]: 276
0x00016dfa xfs_bmap_add_extent_delay_real [xfs]: 252
0x0003b4dc xfs_bulkstat [xfs]: 252
0x0004acb0 _xfs_trans_commit [xfs]: 240
0x00018c1e xfs_bmap_del_extent [xfs]: 236
0x000529a4 xfs_symlink [xfs]: 236
0x0002e3c0 xfs_growfs_data [xfs]: 228
0x0003a6fa xfs_iomap_write_delay [xfs]: 224
0x0001f282 xfs_bmbt_delrec [xfs]: 216
0x00020335 xfs_bmbt_split [xfs]: 212
0x00014d4b xfs_bmap_add_extent_unwritten_real [xfs]: 204
0x00028658 xfs_dir2_leaf_getdents [xfs]: 204
0x00019dc8 xfs_bunmapi [xfs]: 200
0x0001c89d xfs_getbmap [xfs]: 200
0x00046b97 xfs_mountfs [xfs]: 200
0x0004fc95 xfs_free_file_space [xfs]: 200
...
(OTOH, my FC6 mythbox has been just fine for a year on xfs over plain
partitions)
-Eric
11:23 p.m.
Eric Sandeen wrote:
Eric Sandeen wrote:
> 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).
I can confirm that xfs on 4KSTACKS over lvm is still a problem.
Basic functionality is fine, but I can't make it through all of xfsqa
w/o a stack overflow. Even just mounting with -o quota gets us pretty
close to the edge:
mount used greatest stack depth: 180 bytes left
I'll look at some of the bigger offenders if I have any spare time in
the evenings. It's the callchains, too though, not just the individual
functions that come into play.
Ok, some good news on this front. With a handful of changes, I got
these stack reductions:
xfs_alloc_file_space [xfs]: 184 176 : -8
xfs_bmap_adjacent [xfs]: 120 136 : +16
xfs_bmapi [xfs]: 276 268 : -8
xfs_bunmapi [xfs]: 200 172 : -28
xfs_create [xfs]: 116 100 : -16
xfs_free_file_space [xfs]: 200 132 : -68
xfs_getbmap [xfs]: 200 204 : +4
xfs_iomap_write_direct [xfs]: 180 168 : -12
xfs_link [xfs]: 96 88 : -8
xfs_mkdir [xfs]: 116 96 : -20
xfs_mountfs [xfs]: 200 152 : -48
xfs_qm_dqusage_adjust [xfs]: 52 48 : -4
xfs_qm_vop_chown_reserve [xfs]: 48 44 : -4
xfs_read [xfs]: 72 48 : -24
xfs_remove [xfs]: 96 84 : -12
xfs_rename [xfs]: 144 136 : -8
xfs_rmdir [xfs]: 92 76 : -16
xfs_setattr [xfs]: 132 116 : -16
xfs_splice_read [xfs]: 36 16 : -20
xfs_splice_write [xfs]: 56 36 : -20
xfs_unmount [xfs]: 52 4 : -48
xfs_write [xfs]: 144 124 : -20
----------------------
Functions increased: 2
Functions decreased: 20
Net change: -388
and I can now survive xfsqa over lvm on 4KSTACKS. I still get within
spitting distance of the end of the stack though. :)
I've put the stack-reducing changes & a few bugfixes into
kernel-2.6.23-0.133.rc3.git6.fc8, building now.
-Eric
11:38 p.m.
Jesse Keating wrote:
On Thu, 26 Jul 2007 16:32:30 -0500
Dan Yocum <yocum(a)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? And why can't I boot from xfs
yet?
Not addressing either of these questions directly, but with regard to
overall quality of xfs in F8... I ran the xfsqa test suite on
2.6.23-0.71.rc2.fc8 over the weekend. Of the "auto" test group (those
expected to pass reliably), 90 of 93 tests passed (this after fixing a
quota bug I found & fixed over the weekend). Of the 3 failures, 2 are
"harmless" - i.e. no data corruption, security issues, or anything like
that - one is a bleeding-edge allocator feature not working quite 100%,
another has to do with slightly different log traffic pattern due to a
recent change w.r.t. the expected output.
The "real" failure has to do with mmap writes into preallocated space;
I'll look into that as I have time.
just FYI,
-Eric
12:01 a.m.
On Mon, 2007-08-06 at 23:38 -0500, Eric Sandeen wrote:
Jesse Keating wrote:
> On Thu, 26 Jul 2007 16:32:30 -0500
> Dan Yocum <yocum(a)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? And why can't I boot from xfs
> yet?
Not addressing either of these questions directly, but with regard to
overall quality of xfs in F8... I ran the xfsqa test suite on
2.6.23-0.71.rc2.fc8 over the weekend. Of the "auto" test group (those
expected to pass reliably), 90 of 93 tests passed (this after fixing a
quota bug I found & fixed over the weekend). Of the 3 failures, 2 are
"harmless" - i.e. no data corruption, security issues, or anything like
that - one is a bleeding-edge allocator feature not working quite 100%,
another has to do with slightly different log traffic pattern due to a
recent change w.r.t. the expected output.
The "real" failure has to do with mmap writes into preallocated space;
I'll look into that as I have time.
Don't we ship Fedora with 4K stacks, so I've heard XFS + RAID stuff can
overflow the stack..
so it may not be the stable..
Dave.
9:57 a.m.
Dave Airlie wrote:
On Mon, 2007-08-06 at 23:38 -0500, Eric Sandeen wrote:
> Jesse Keating wrote:
>> On Thu, 26 Jul 2007 16:32:30 -0500
>> Dan Yocum <yocum(a)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? And why can't I boot from xfs
>> yet?
> Not addressing either of these questions directly, but with regard to
> overall quality of xfs in F8... I ran the xfsqa test suite on
> 2.6.23-0.71.rc2.fc8 over the weekend. Of the "auto" test group (those
> expected to pass reliably), 90 of 93 tests passed (this after fixing a
> quota bug I found & fixed over the weekend). Of the 3 failures, 2 are
> "harmless" - i.e. no data corruption, security issues, or anything like
> that - one is a bleeding-edge allocator feature not working quite 100%,
> another has to do with slightly different log traffic pattern due to a
> recent change w.r.t. the expected output.
>
> The "real" failure has to do with mmap writes into preallocated space;
> I'll look into that as I have time.
Don't we ship Fedora with 4K stacks, so I've heard XFS + RAID stuff can
overflow the stack..
so it may not be the stable..
Yeah, I talked about 4k stacks earlier in this thread - 4k stacks on x86
can cause xfs to run into trouble with more "interesting" io stacks.
(though there are non-trivial cases where ext3 can blow through 4k as
well; see recent LKML threads on 4k stacks...)
The testing above, though, was on x86_64 with a larger stack size.
-Eric
4:47 p.m.
On Tue, Aug 07, 2007 at 08:41:27PM +0530, Rahul Sundaram wrote:
Eric Sandeen wrote:
>
> Yeah, I talked about 4k stacks earlier in this thread - 4k stacks on x86
> can cause xfs to run into trouble with more "interesting" io stacks.
Does "interesting" here translate to "we can lose data"?
With a stack overflow, you'll usually just end up with a hung computer.
Dave
--
http://www.codemonkey.org.uk
11:41 p.m.
Dave Airlie wrote:
On Mon, 2007-08-06 at 23:38 -0500, Eric Sandeen wrote:
> Jesse Keating wrote:
>> On Thu, 26 Jul 2007 16:32:30 -0500
>> Dan Yocum <yocum(a)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? And why can't I boot from xfs
>> yet?
> Not addressing either of these questions directly, but with regard to
> overall quality of xfs in F8... I ran the xfsqa test suite on
> 2.6.23-0.71.rc2.fc8 over the weekend. Of the "auto" test group (those
> expected to pass reliably), 90 of 93 tests passed (this after fixing a
> quota bug I found & fixed over the weekend). Of the 3 failures, 2 are
> "harmless" - i.e. no data corruption, security issues, or anything like
> that - one is a bleeding-edge allocator feature not working quite 100%,
> another has to do with slightly different log traffic pattern due to a
> recent change w.r.t. the expected output.
>
> The "real" failure has to do with mmap writes into preallocated space;
> I'll look into that as I have time.
FWIW that turned out to be a non-error as well, test assumed 16k pages.
Don't we ship Fedora with 4K stacks, so I've heard XFS + RAID
stuff can
overflow the stack..
so it may not be the stable..
I'll test on x86 over lvm some evening or next weekend. It is a
concern. My x86 mythbox is perfectly happy on FC6, though, running xfs
on plain partitions (no lvm).
-Eric
6089
days inactive
6118
days old
29 comments
13 participants
participants (13)
-
Callum Lerwick -
Dan Yocum -
Dave Jones -
David Airlie -
David Cantrell -
David Chambers -
Douglas McClendon -
Eric Sandeen -
Eric Sandeen -
Jarod Wilson -
Jesse Keating -
Nicolas Mailhot -
Rahul Sundaram