Hi Andrew,
On Tue, 10 Mar 2009 15:54:59 -0700, Andrew Morton wrote:
> On Wed, 11 Mar 2009 01:55:42 +0900 (JST)
> Ryusuke Konishi <konishi.ryusuke@xxxxxxxxxxxxx> 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 picking up additional patches at all times!
> > (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.
Oops, sorry, I mistook; it meant forward-compatibility.
My recent patch series and the recent userland tasks were intended to
give better support for future extensions though I even tried to keep
backward compatibility.
> 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.
Thanks for the advice. I'll keep this comment in mind and will handle
matters more flexibly with considering long term merits and trade-off.
> 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.
Yes, I recognize the importance of this. For example, I've carefully
converted both userland and kernel code so that they refer to ``size''
fields embeded in on-disk structures instead of calculating with
sizeof(). In addition, I paid attention to initialization of reserved
fields not to break the forward compatibility.
We arranged various size fields: size of super block, size of segment
header, size of on-disk items in meta data files such as inode on
ifile, checkpoint entry on cpfile, segment usage entry on sufile, and
so forth. All those fields are for handling possible future
extensions.
Further, each log of nilfs2 is designed so that it can have additional
blocks in the tail. They may be used, for instance, to write
additional copies of superblock.
> 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.
Got it. So, I will do the message insertion :)
> 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.
Great!
Regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
