Prev: uml: pthreads instead of manual clone()?
Next: [PATCH 06/11] viafb: Determine type of 2D engine and store it in chip_info
From: Christoph Hellwig on 18 Apr 2010 14:10
The merge window for Linux 2.6.34 closed in the first week of March,
with the important XFS features already landing in February. Not
surprisingly the XFS merge activity in March has been rather slow,
with only about a dozen bug fixes patches making it towards Linus'
tree in that time.
On the other hand active development for the 2.6.35 merge window has
been very active. Most importantly there was a lot of work on the
transaction and log subsystems. Starting with a large patchset to
clean up and refactor the transaction subsystem and introducing more
flexible I/O containers in the low-level logging code work is
progressing to a new, more efficient logging implementation. While
this preparatory work has already been merged in the development tree,
the actual delayed logging implementation still needs more work after
the initial public posting. The delayed logging implementation which
is very briefly modeled after the journaling mode in the ext3/4
and reiserfs filesystems allows to accumulated multiple asynchronous
transactions in memory instead of possibly writing them out
many times. Using the new delayed logging mechanism I/O bandwidth
used for the log decreases by orders of magnitude and performance
on metadata intensive workloads increases massively.
In addition to that a new version of the discard (aka TRIM) support
has been posted, this time entirely contained in kernel space
and without the need of a userspace utility to drive it. Last but
not least the usual steady stream of cleanups and bug fixes has not
ceased this month either.
Besides the usual flow of fixes and new test cases in the xfstests
test suite development on the userspace side has been rather slow.
Xfsprogs has only seen a single fix for SMP locking in xfs_repair
and support for building on Debian GNU/kFreeBSD, and xfsdump
has seen no commit at all.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/