Messages in this thread | | | Date | Tue, 6 Jan 2009 15:28:29 -0800 | From | Andrew Morton <> | Subject | Re: 2.6.29 -mm merge plans |
| |
(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)
| |