Re: 2.6.29 -mm merge plans

[Andrew Morton <akpm@linux-foundation.org>]

(cc added)

On Tue, 6 Jan 2009 17:57:44 -0500
Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Jan 05, 2009 at 12:43:00AM -0800, Andrew Morton wrote:
> 
> > nilfs2-add-document.patch
> > nilfs2-disk-format-and-userland-interface.patch
> > nilfs2-add-inode-and-other-major-structures.patch
> > nilfs2-integrated-block-mapping.patch
> > nilfs2-b-tree-based-block-mapping.patch
> > nilfs2-direct-block-mapping.patch
> > nilfs2-b-tree-node-cache.patch
> > nilfs2-buffer-and-page-operations.patch
> > nilfs2-meta-data-file.patch
> > nilfs2-persistent-object-allocator.patch
> > nilfs2-disk-address-translator.patch
> > nilfs2-inode-map-file.patch
> > nilfs2-checkpoint-file.patch
> > nilfs2-segment-usage-file.patch
> > nilfs2-inode-operations.patch
> > nilfs2-inode-operations-fix.patch
> > nilfs2-file-operations.patch
> > nilfs2-directory-entry-operations.patch
> > nilfs2-pathname-operations.patch
> > nilfs2-pathname-operations-fix.patch
> > nilfs2-operations-for-the_nilfs-core-object.patch
> > nilfs2-super-block-operations.patch
> > nilfs2-super-block-operations-fix.patch
> > nilfs2-segment-buffer.patch
> > nilfs2-segment-constructor.patch
> > nilfs2-recovery-functions.patch
> > nilfs2-another-dat-for-garbage-collection.patch
> > nilfs2-block-cache-for-garbage-collection.patch
> > nilfs2-ioctl-operations.patch
> > nilfs2-update-makefile-and-kconfig.patch
> > #
> > nilfs2-fix-problems-of-memory-allocation-in-ioctl.patch
> > nilfs2-cleanup-nilfs_clear_inode.patch
> > nilfs2-avoid-double-error-caused-by-nilfs_transaction_end.patch
> > nilfs2-insert-explanations-in-gcinode-file.patch
> > nilfs2-add-maintainer.patch
> > nilfs2-fix-gc-failure-on-volumes-keeping-numerous-snapshots.patch
> > 
> >   Dunno.   Has this been reviewed enough?
> 
> No.  I might eventually take a look, but looking into btrfs has a little
> higher priority right now, and split into gazillions of
> non-selfcontained patches certainly doesn't help reviewing it.

nilfs will remain under development for a couple of months and we'll
take a look at a 2.6.20 merge.  Can you please find time to take a
closer look during this cycle?

> BTW, the current influx of higher-complexity filesystems certainly worries
> me a little.

Well yes.  Each new filesystem (complex or not) is an additional
boatanchor on development of core kernel: block, vfs, MM, etc.  So each
filesystem should be justified on the basis that it adds sufficient
benefit to justify that cost.  (And I got mau-muaed for pointing this
out in the omfs context, I might add).

Will nilfs bring enough value to justify it's cost?  Hard call.  What
do you think?

(otoh, we could probably randomly delete ten old filesystems and
practically nobody would notice)