5 ms·
All open source developers want users. Users means more bug reports and often more developers to contribute to the prokect. In addition, the greater relevanc
by tytso 15y ago
All open source developers want users. Users means more bug reports and often more developers to contribute to the prokect. In addition, the greater relevance also means it's more likely they will be able to get companies to be able to pay for them to do what they do, conferences to invite them to talk about their projects, etc. (It's for this reason that when the IMHO over-aggressive enforcement of busybox license forcing people who get sued to release code on code unrelated to busybox has caused FUD amongst Linux embedded companies, the emergency of a replacement toybox project which avoids these issues has caused so much dismay amongst the busybox development community.)
Given that Dave Chinner is one of the primary developers of XFS, it's not surprising that he wants to promote XFS. And to be fair, XFS has not gotten as much attention as it has perhaps deserved based on technical considerations alone (as has other perfectly capable filesystems at the their time, such as JFS) and that's no doubt frustrated him. In addition, the work he has done to improve XFS removes one of the significant performance bottlenecks often seen by desktop users and developers, and he should be saluted for that.
That being said, it's also true that in many cases the file system is not the bottleneck, and so other issues that aren't tightly focused on performance (i.e., the quality of the userspace tools such as e2fsck and debugfs for ext4, and their equivalent or lack thereof in other file systems), familiarity by sysadmins, data recovery services, etc., ease of upgrading of existing large, production file systems, and so on.
In addition, it's dangerous to draw conclusions from a single microbenchmark such as fs_mark alone. It's not common that you have workloads which create thousands and thousands of small (< 64k) files in parallel across lots of CPU cores at the same time, on the same file system. So using this this benchmark alone to say that file system X is more scalable than file system Y is just not going to tell the whole story. Personally, I like to use microbenchmarks as a tool for improving a file system, and not as an argument to try to get people to switch from one file system to another. Unless someone's use case is exactly mirrored by the microbenchmark, I personally find this approach to be a little dishonest.
I will say that at the moment, many of the developers who have been working on ext4 are employed by companies who are using ext4 as part of a cloud data storage stack. This is why there has been changes such as no journal mode (which is great when you have consistency guarantees being provided by a cluster file system above you, since they have provide the file even if an entire server's power supply has exploded), and good performance when under severe memory pressure (funny how most benchmarks are done when the only thing running on the server is the benchmark, so there is no competition for the CPU and for system memory --- XFS in particular have proven to be a memory hog, and others have noted severe performance degredations and in some cases stability problems, under memory pressure; not a problem on a stand-alone file server, but not so great if you are also trying to run VM's or other applications using the file system on the same machine). Arguably some of these improvements don't mean as much for desktop users, although I believe some of the performance enhancements we've made have also trickled down to help the desktop.
XFS, in contrast, has been focusing a lot of attention on the desktop use case, and they've traditionally owned the big stream writes, HPC workloads using huge servers, huge memory, and huge RAID arrays. It's good that XFS has made these improvements, and I salute them for it. But to state that these two workloads are the only ones which are important, and therefore they are the file system of the future, may be overstating matters --- with all due respect to Dave and his many years of experience working on XFS.
- zanny 15y agoReading the post, a lot of what he says is that XFS scales better than ext4 due to better algorithmic implementations of various "things". Why not just get active with ex4 (more likely 5) development and work to introduce his performance improvements into the main line file system already in use?
- tytso 15y agoHis performance improvements are very specific to XFS; arguably they were fixing a problem/fundamental design issue in the original journaling code in XFS. Ext4's journaling code is very, very different from XFS. So a design improvement that applies to XFS is not necessarily applicable to ext4. That being said, there have been times when we've looked at what XFS has done with some feature (such as delayed allocation writeback for example) and written code which has been inspired by XFS's algorithms. I'm an engineer, I'll take good ideas from wherever I can. (Unless I suspect there may be legal reasons why I had better stay away from certain techniques :-/) Also, the scalability issues that Dave has been talking about aren't ones that matter for any of the workloads that the ext4 developers or their employers care about. We don't have 32 CPU cores all writing small files and requiring small block allocations to a single file system at the same time. So yes, there are scalability problems which he has identified with that specific benchmark that Dave was experimenting with (fs_mark) where ext4 has its own performance problems that could be fixed with the appropriate developer attention. It's on my list to look at and hopefully address, but I have higher priority things that do benefit the workloads that my company is interested in. For example, I am currently working on making Async I/O truly Async even when we need to read metadata blocks, which is a bug that all file systems suffer from under Linux; AIO is not truly "A". This is something that has been known for over a decade, but up until now, no one who was funding fs development, for ext4 or XFS, has had a workload where this has mattered enough. When I do fix this, it will be an area where ext4 will have an advantage over XFS. Will I then trumpet this as the reason why they should switch from XFS to ext4? Of course not. Not everyone has a need for true Async I/O. On the other hand, if ext4 has such a feature, it may appeal to some application writers, probably of various different storage servers or perhaps web servers, and if they start using it, then there may be more workloads where true AIO is relevant. And that in turn might inspire XFS developers to add a similar feature. This is why I've always believed competition is a good thing, and why I've never argued that fs developers should abandon one file system and go work on another file system. (As Dave has done on the linux-ext4 list, but never mind that.)