On 10/9/2011 6:27 PM, Bron Gondwana wrote: > On Sun, Oct 09, 2011 at 06:03:36PM -0500, Stan Hoeppner wrote:
>> XFS has been seeing substantial development for a few years now due to >> interest from RedHat, who plan to make it the default RHEL filesystem in >> the future. They've dedicated serious resources to the effort, >> including hiring Dave Chinner from SGI. Dave's major contribution while >> at RedHat has been the code that yields the 10X+ increase in unlink >> performance. It is enabled by default in 2.6.39 and later kernels. > > Fair enough. It's good to see the extra work going in. It's been the premier Linux filesystem for big data jobs since it was originally ported from IRIX to Linux. It's been the only filesystem on SGI's 512 socket Altix NUMA servers since their introduction in 2003. It's always been production quality on Linux. Until relatively recently it wasn't really suited as a general purpose server filesystem due to the (lack of) metadata write performance and some other minor issues. AIUI, addressing these has been Red Hat's focus so XFS is more useful to a wider general server audience. The reason I state this is that many uninformed general computing Linux users [have] consider[d] XFS some kind of perennially experimental basement Linux filesystem, which is not the case. > Corruption happens for real. We get maybe 1-2 per month on average. > Wouldn't even notice them if we didn't actually have the sha1 of > every single email file in the metadata files, and THAT protected > with a crc32 per entry as well. So we can actually detect them. I was referring to filesystem corruption, not file corruption. > Seriously? I do actually build my own kernels still, but upgrading is > always an interesting balancing act, random bits of hardware work > differently - stability is always a question. Apparently I should have been more specific, even though my statement was in direct context of the proceeding. I was referring specifically to filesystem patches. The QC process for Linux FS patches is such that you're not going to see any functional bug hit mainline. Interestingly, the XFS test validation suite is used for all Linux filesystems. I'll leave it to the readers to dig up the background on why this is the case. > Upgrading to a new gnome release is much less risky. Should I have used KDE? I was attempting to conjure Linus quotes in folks' minds WRT Gnome3 being an unusable disaster. He said the same of KDE4. > Well, yeah. I've heard interestingly mixed things from people running > ZFS too, but mostly positive. We keep our backups on ZFS on real > Solaris - at least one lot. The others are on XFS on one of those huge > SAN thingies. But I don't care so much about performance there, > because I'm reading and writing huge .tar.gz files. And XFS is good > at that. Always has been, especially many in parallel. Now it's finally good at maildir and spools as well, and better than the others at high concurrency levels with sufficient hardware. I never bought into the ZFS hype. For better or worse I'm a Linux guy (Debian), and probably won't be using Solaris or *BSD any time soon. When BTRFS is finally feature complete and has some legs under it I'll kick its tires. Maybe it'll give XFS a run for its money on some workloads. I suspect the new unique features will drive BTRFS adoption, not pure performance, at least not initially. I'm guessing that with some workloads it'll never be able to surpass XFS performance. Good discussion, enjoyable. I wish it wasn't quite so OT at this point. It'll be nice to get some filesystem performance info related to Postfix into Google, though I think we only had a few of the posts out of many accomplish that. I think we need to end this OT discussion out of respect for Wietse and others, unless we get back on track with filesystem stuff as it relates directly to Postfix. If anyone would like to continue discussing XFS optimization with mail server workloads it would great to have such a thread on the XFS list: http://oss.sgi.com/mailman/listinfo/xfs -- Stan
