User: Password:
|
|
Subscribe / Log in / New account

XFS: the filesystem of the future?

XFS: the filesystem of the future?

Posted Jan 22, 2012 15:06 UTC (Sun) by dgc (subscriber, #6611)
In reply to: XFS: the filesystem of the future? by and
Parent article: XFS: the filesystem of the future?

> my comment was not meant as an attack on XFS

I didn't take it that way - I was trying to explain what it meant ;)

> (I think it's a really
> nice file system and I even used it for a while), I was just wondering
> about the IMHO glaring discrepancy between the article's text and the
> actual results shown.

There's always the problem of context. Jon has done a pretty good job of communicating my message, but it's hard to convey all the context that I put around those charts. IOWs, for explanations of the finer details of the charts you really should watch the video first - I do actually explain that ext4 is faster for 1-2 threads on most of the workloads I presented and I explain why that is the case, too...

> On a different matter: does XFS still scale (almost) linearly for
> 16 or 32 threads? if yes, neither XFS nor the VFS layer are probably
> hitting the scalability wall.

That's in the talk, too, and I think Jon mentioned it in the article. ;)

For some raw numbers at 16 threads, XFS performance increases from about 100k file creates/s to about 130k file creates/s, but CPU usage doubles and most of it is wasted spinning on the contended VFS inode and dentry cache LRU locks. I have some patches that I'm working on to minimise that problem.

> to summarize how I understood you: you recommend using XFS for "big
> storage" systems, while -- for the time being -- the desktop use-case
> is still better served by ext4?

No, that's exactly the opposite of what I am saying. My point is that even for desktop use cases, XFS is now so close ext4 performance on single threaded metadata intensive workloads that it ext4 has lost the one historical advantage it held over XFS.

The example I use in the talk is untarring a kernel tarball - XFS used to take a minute, ext4 about 3s. That's one of the common "20x slower" workloads that people saw all the time. Now XFS will do that same untar in 4s. And the typical 50x slower workload was then doing a 'rm -rf' on that unpacked kernel tarball. XFS has gone from about a minute down to 3s, compared to 2s for ext4....

While these XFS numbers are still slightly slower from a "benchmark perspective", in practice most people will consider them both to be "instantaneous" because they now both complete faster than the time it takes to type your next command. IOWs, users will notice no practical difference between the performance of the filesystems for common desktop/workstation usage.

Let's now fast forward a few months: your desktop and server system filesystems will be BTRFS, whilst XFS is fast enough and scales well enough for everything else that BTRFS can't be used for. I can't see where ext4 fits into this picture because, AFAIC, XFS is now the better choice for just about every workload you wouldn't use BTRFS for....

So I'm not sure ext4 has a future - ext4 was always intended as a stop-gap measure until BTRFS is ready to take over as the default linux filesystem. This milestone is rapidly approaching, so now is a good time to look at the future of the other filesystems that are typically used on systems. Everyone knows what I think now, so I'm very interested in what users and developers think about what I've said and the questions I've posed. The upcoming LSF workshop could be very interesting. :)

Dave.


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds