XFS status update for February 2010
From: Christoph Hellwig
Date: Sat Mar 06 2010 - 11:17:28 EST
February saw the release of the Linux 2.6.33 kernel, which includes
a large XFS update. The biggest user-visible change in Linux 2.6.33
is that XFS now support the generic Linux trace event infrastructure,
which allows tracing lots of XFS behavior with a normal production
built kernel. Except for this Linux 2.6.33 has been mostly a bug-fix
release, fixing various user reported bugs in previous releases.
The total diffstat for XFS in Linux 2.6.33 looks like:
84 files changed, 3023 insertions(+), 3550 deletions(-)
In addition to that the merge window for Linux 2.6.34 opened and the
first merge of the XFS tree made it into Linus tree. Unlike Linux
2.6.33 this merge window includes major feature work. The most
important change for users is a new algorithm for inode and quota
writeback that leads to better I/O locality and improved metadata
performance. The second big change is a rewrite of the per-allocation
group data lookup which fixes a long-standing problem in the code
to grow a life filesystem and will also ease future filesystem
shrinking support. Not merged through the XFS tree, but of great
importance for embedded users is a new API that allows XFS to properly
flush cache lines on it's log and large directory buffers, making
XFS work properly on architectures with virtually indexed caches,
such as parisc and various arm and mips variants. Last but not
least there is an above average amount of cleanups that went into
Linus tree in this cycle.
There have been more patches on the mailing list that haven't made
it to Linus tree yet, including an optimized implementation of
fdatasync(2) and massive speedups for metadata workloads on
NFS exported XFS filesystems.
On the userspace side February has been a relatively quite month.
Lead by xfstests only a moderate amount of fixes made it into
the respective trees.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/