His performance improvements are very specific to XFS; arguably they were fixing a problem/fundamental design issue in the original journaling code in XFS. Ext

His 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.)