for what it's worth, XFS has had a lot of attention in the last 3 years or so.
when it was initially merged it had a _lot_ of SGI baggage (shim layers between the XFS code and the rest of the kernel). it has had a lot of cleanup and maintinance, including a lot of testing (and the development of a filesystem test suite that other filesystems are starting to adopt since they don't have anything as comprehensive)
so while I have been using XFS for about 7 years, I would not be surprised to hear that people had problems about 5 years ago. I would be surprised if those problems persisted to today.
personally, I don't trust Ext4 yet, it's just too new, and it's still finding corner cases that have problems. It also is not being tested against multi-disk arrays very much (the developers don't have that sort of hardware, so they test against what they have)
Posted Feb 14, 2011 17:02 UTC (Mon) by rahulsundaram (subscriber, #21946)
[Link]
Yes I am assuming that people are talking about current Ext4 and XFS code rather than historical issues.
"It also is not being tested against multi-disk arrays very much (the developers don't have that sort of hardware, so they test against what they have)"
IIRC, this was tested by Red Hat before making it default in RHEL 6. That however is not the very latest Ext4 code.
Removing ext2 and/or ext3
Posted Feb 14, 2011 17:12 UTC (Mon) by dlang (✭ supporter ✭, #313)
[Link]
I made the statement about testing based on posts to the kernel mailing list by the developers.
yes, redhat did testing, but I'll bet that their testing was of the 'does it blow up' type of thing rather than performance testing.
In any case, the fact that the developers are not testing against that type of disk subsystem means that they are not looking for, or achieving the best performance when used with those subsystems (this was also confirmed by the Ext4 devs on the kernel mailing list)
I'm not saying that the Ext4 devs are incompetent or not doing the best that they can with what they have, just that the fact that they are not working with such large systems means that they are not running into the same stresses in their testing and profiling that people will run into in the real world with large systems.
the current XFS devs may or may not have access to such large arrays nowdays, but historically SGI was dealing with such arrays and did spend a lot of time researching how to make the filesystem as fast as it could be on such arrays, and that knowledge is part of the design of XFS. the current maintainers could destroy this as they are updating it, but this is not very likely.
Removing ext2 and/or ext3
Posted Feb 14, 2011 17:51 UTC (Mon) by rahulsundaram (subscriber, #21946)
[Link]
"yes, redhat did testing, but I'll bet that their testing was of the 'does it blow up' type of thing rather than performance testing"
I wouldn't bet on that. Red Hat has a fairly large filesystem team and performance team and run performance tests routinely, for public benchmarks (useful to convince customers) and otherwise. All the major Ext4 and XFS developers work for large vendors (Google, IBM, Red Hat etc) and I would have expected them to have access to enterprise hardware. XFS is known to scale better on big hardware atleast historically because of its legacy but the gap has reduced considerably in recent kernel versions.
Removing ext2 and/or ext3
Posted Feb 14, 2011 17:53 UTC (Mon) by dlang (✭ supporter ✭, #313)
[Link]
the last discussion I saw on this topic was within the last two kernel versions, and it was a report of bad behavior on large systems like this and the Ext4 dev (I think it was Ted, but I'm not sure) stated at that time that the ext4 devs did not have access to large systems for their testing at that time.