lkml.org 
[lkml]   [2009]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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)


    \
     
     \ /
      Last update: 2009-01-07 00:31    [W:5.367 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site