All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Cc: hch@lst.de, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, konishi.ryusuke@lab.ntt.co.jp
Subject: Re: Asking for inclusion of nilfs2 in the mainline kernel
Date: Tue, 10 Mar 2009 15:54:59 -0700	[thread overview]
Message-ID: <20090310155459.11ffa81f.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090311.015542.118514963.ryusuke@osrg.net>

On Wed, 11 Mar 2009 01:55:42 +0900 (JST)
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> wrote:

> I've been working for the past serveral months to take review comments
> and to continually solve users' problems come up in mainling list

Yes, the maintenance has been impressive.

> (thanks for all giving comments and feedbacks!).  Also, I've tried to
> stabilize API and disk format to restrict additional changes and
> ensure backward compatibility.

Well.  From the point of view of mainline linux, there is no
back-compatibility issue, because the fs hasn't been merged yet.

You perhaps have back-compatibility concerns for existing users of the
out-of-tree patch, but I'd encourage you to not worry about that too
much - there will be fairly few users and they are probably pretty
technical and will be able to cope with a migration.  It's a _bit_ hard
on them but on the other hand, omitting back-compatibility code leads
to a better implementation for the long term.

What you should be more concerned about is forward-compatibility.  What
arrangements do you presently have in place to be able to later alter the
on-disk format without causing too much disruption?  Having a strong
design here will make changes easier to do and will lead to a better
filesystem.

Also..  Don't get _too_ concerned about freezing the on-disk format at
this time.  You could put in a mount-time printk("the nilfs on-disk
format may change at any time - do not place critical data on a nilfs
filesystem") and we leave that in place for a few months while things
stabilise.

And yes, I was planning on sending nilfs in to Linus for 2.6.30 unless
someone has decent-sounding reasons to hold it back.

  parent reply	other threads:[~2009-03-10 22:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-10 16:55 Asking for inclusion of nilfs2 in the mainline kernel Ryusuke Konishi
2009-03-10 17:46 ` Sitsofe Wheeler
2009-03-10 18:54   ` Ryusuke Konishi
2009-03-10 18:25 ` Greg KH
2009-03-10 19:23   ` Ryusuke Konishi
2009-03-10 22:54 ` Andrew Morton [this message]
2009-03-11  8:35   ` Ryusuke Konishi
2009-03-13  7:21     ` Ryusuke Konishi
2009-03-13  8:05 ` Alex Riesen
2009-03-13  8:05   ` Alex Riesen
2009-03-13 10:04   ` Ryusuke Konishi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090310155459.11ffa81f.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=hch@lst.de \
    --cc=konishi.ryusuke@lab.ntt.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.