XFS still gets dorked with?

Posted Jan 24, 2011 15:09 UTC (Mon) by pr1268 (guest, #24648)
In reply to: Kernel prepatch 2.6.38-rc2 by nowster
Parent article: Kernel prepatch 2.6.38-rc2

Just curious, how come XFS still gets futzed with this late in the game? Hasn't XFS been in the kernel for years?

As I've said before, I'm often ignorant of kernel and userspace development, and perhaps XFS (like other file systems) is a moving target due to technological advances in storage media (like SSDs, etc.). Thanks for any enlightenment!

XFS still gets dorked with?

Posted Jan 24, 2011 15:39 UTC (Mon) by roblucid (guest, #48964) [Link]

Yes, but XFS is not an isolated program, but a component of the Linux Kernel. When that environment changes, XFS has to change with it to use altered kernel interfaces, or to provide new features requiring support from the XFS code needed by other parts of the kernel.
The lack of stable interfaces inside the Kernel is a feature and the way the developers like it, so no part of Linux could be fossilised, but has to evolve from release to release; which is more flexible and adaptable than setting a rigid design in stone.

XFS still gets dorked with?

Posted Jan 24, 2011 17:43 UTC (Mon) by iabervon (subscriber, #722) [Link] (1 responses)

XFS was developed outside of the Linux kernel and has a tendency to depend on VFS behavior that not all Linux filesystems depend on. This means that bugs in VFS changes are often theoretical except for on XFS. Even aside from intended API changes requiring corresponding changes in filesystems, there's the possibility of unintended API changes that either need to be made more carefully or need to be made explicit so that filesystems can be updated. Of course, bugs that affect ext3 (or proc or sysfs) tend not to get very far unnoticed, so it tends to be the case that a VFS patch that makes it to Linus's tree with a bug will break only XFS (or NFS, which does a different set of unusual things that are supposed to work).

And there were some fairly significant changes to core code, including the VFS, in this cycle, so it's not too surprising that there are subtle interactions.

XFS still gets dorked with?

Posted Jan 24, 2011 21:27 UTC (Mon) by dgc (subscriber, #6611) [Link]

> XFS was developed outside of the Linux kernel and has a tendency to
> depend on VFS behavior that not all Linux filesystems depend on.

Not any more. XFS is now as integrated with the VFS and generic code as any other native Linux filesystem. The majority of problems we find in XFS have nothing to do with changes to the VFS or generic code. They are typically regressions from recent XFS changes that weren't caught by xfstests or corner case issues that have been in the code base for 15 years. In this case, the problem reported by the OP is a very recent regression introduced by changes to speculative preallocation...

Cheers,

Dave.

XFS still gets dorked with?

Posted Jan 24, 2011 21:07 UTC (Mon) by dgc (subscriber, #6611) [Link] (3 responses)

Doesn't matter how long something has been around, it can still be improved. Code cleanups, shiny new go-fast features (e.g delayed logging), scalability improvements (e.g. lockless transaction reservation fast path), IO pattern improvements (e.g. optimised delayed writeback of metadata), etc are being made all the time.

Indeed, XFS has had a greater rate of code change that even btrfs since 2.6.32:

$ git diff --stat v2.6.32.. -- fs/xfs |tail -1
141 files changed, 14887 insertions(+), 16766 deletions(-)
$ git diff --stat v2.6.32.. -- fs/btrfs |tail -1
49 files changed, 13019 insertions(+), 5162 deletions(-)
$ git diff --stat v2.6.32.. -- fs/ext4 fs/jbd2 |tail -1
37 files changed, 6707 insertions(+), 3862 deletions(-)

By this metric, you could say that XFS is the most actively developed filesystem in Linux. :)

As a result, we do occasionally have a bug slip through the dev tree into a mainline tree, but that's why we have the -next tree and a series of -rc releases. The wider developer and tester commmunity will catch most problems like this before a full release is made. i.e. the process is working the way it should....

Cheers,

Dave.

XFS still gets dorked with?

Posted Jan 25, 2011 9:48 UTC (Tue) by dgm (subscriber, #49227) [Link] (2 responses)

Very nice to see XFS in good shape. But what I read in those statistics is slightly different.

Less lines were added to XFS than they were removed. That may mean code that's being heavily revisited, possible because it has languished somehow and is now being cleaned up?

Btrfs, on the other hand, adds far more lines that it removes, suggesting that its being developed and adding features at a fast pace. The difference in added lines between XFS and Btrfs is roughly 10%, not that much.

Finally, ext4 looks much more quiet. Adding features and fixing stuff here and there.

It would be nice to know the different sizes of each code base, but I assume they are comparable.

XFS still gets dorked with?

Posted Jan 25, 2011 12:09 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> It would be nice to know the different sizes of each code base, but I assume they are comparable.

$ sloccount fs/xfs
[...]
SLOC Directory SLOC-by-Language (Sorted)
47802 top_dir ansic=47802
11840 linux-2.6 ansic=11840
4628 quota ansic=4628
145 support ansic=145

Totals grouped by language (dominant language first):
ansic: 64415 (100.00%)
[...]

$ sloccount fs/btrfs
[...]
SLOC Directory SLOC-by-Language (Sorted)
46176 btrfs ansic=46148,sh=28

Totals grouped by language (dominant language first):
ansic: 46148 (99.94%)
sh: 28 (0.06%)
[...]

$ sloccount fs/ext4 fs/jbd2
[...]
SLOC Directory SLOC-by-Language (Sorted)
24465 ext4 ansic=24465
4597 jbd2 ansic=4597

Totals grouped by language (dominant language first):
ansic: 29062 (100.00%)
[...]

XFS still gets dorked with?

Posted Jan 25, 2011 15:49 UTC (Tue) by bronson (subscriber, #4806) [Link]

> Less lines were added to XFS than removed. That may mean code that's being heavily revisited ... and is now being cleaned up?

Or it may indicate code that is so good and forward thinking that it was hoisted into the VFS layer. Dunno! It's a bad idea to read too much into statistics alone.