All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viacheslav Dubeyko <slava@dubeyko.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	Vyacheslav.Dubeyko@hgst.com, Cyril.Guyot@hgst.com,
	Adam.Manzanares@hgst.com, Damien.LeMoal@hgst.com
Subject: Re: [PATCH] f2fs: introduce on-disk layout version checking functionality
Date: Fri, 20 May 2016 11:30:43 -0700	[thread overview]
Message-ID: <1463769043.2835.30.camel@slavad-ubuntu-14.04> (raw)
In-Reply-To: <20160520075849.GA8067@infradead.org>

On Fri, 2016-05-20 at 00:58 -0700, Christoph Hellwig wrote:
> Please don't do the mistake of versioning the structure, but instead
> use feature flags, similar to what extN and modern XFS file systems do.

I am not sure that I follow to your point. The F2FS has "feature" field
(__le32 feature) into on-disk superblock (struct f2fs_super_block). The
suggested patch introduces the new F2FS_FEATURE_16TB_SUPPORT flag. And
it looks like as your comment.

So, necessary changes in on-disk layout for 16+TB volumes support will
be incompatible with current available version of F2FS driver. It means
that, anyway, we need to increase version of on-disk layout (major_ver
of struct f2fs_super_block). The presence of superblock's version and
F2FS_FEATURE_16TB_SUPPORT flag will be very useful for consistency
checking by fsck tool.

Another point is file system driver behavior. Old F2FS file system
driver (version 1) should refuse mount operation for the case of version
2 of on-disk layout and F2FS_FEATURE_16TB_SUPPORT flag presence. Or it
could mount in RO mode for the case of absence of
F2FS_FEATURE_16TB_SUPPORT flag and version 2 of on-disk layout. But,
finally, we need to change struct f2fs_inode, struct f2fs_extent and
struct direct_node for the case of version 2 of on-disk layout. It means
that file system driver of version 1 will be unable to mount a volume
with on-disk layout of version 2. The F2FS file system driver of version
2 should support (and mount) volume as for version 1 as for version 2 of
on-disk layout.

Finally, I believe that we need to increase as on-disk layout version
number as to introduce F2FS_FEATURE_16TB_SUPPORT flag. Checking of
version number and F2FS_FEATURE_16TB_SUPPORT flag will provide way of
checking file system volume consistency as for fsck tool as for file
system driver side. Let's imagine a situation that we don't change
on-disk layout version and we will receive superblock with
F2FS_FEATURE_16TB_SUPPORT flag during mount operation. What does it
mean? Does it mean that we have corrupted superblock state? For example,
we could decide that everything is OK. As a result, we will treat struct
f2fs_inode, struct f2fs_extent and struct direct_node in improper way.
It will be the reason of very sophisticated bugs and, potentially,
volume corruptions. 

Could you share your vision in more details?

Thanks,
Vyacheslav Dubeyko.

  reply	other threads:[~2016-05-20 18:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-19 17:46 [PATCH] f2fs: introduce on-disk layout version checking functionality Viacheslav Dubeyko
2016-05-20  7:58 ` Christoph Hellwig
2016-05-20 18:30   ` Viacheslav Dubeyko [this message]
2016-05-23  8:25     ` Christoph Hellwig
2016-05-23 20:08       ` Viacheslav Dubeyko
2016-05-24  8:52         ` Christoph Hellwig
2016-05-25  0:53           ` Viacheslav Dubeyko
2016-05-23 21:13 ` Jaegeuk Kim
2016-05-23 21:13   ` Jaegeuk Kim
2016-05-24  8:53   ` Christoph Hellwig
2016-05-25  0:34     ` Viacheslav Dubeyko
2016-05-25  1:05   ` Viacheslav Dubeyko
2016-05-25 17:12     ` Jaegeuk Kim
2016-05-25 17:46       ` Viacheslav Dubeyko

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=1463769043.2835.30.camel@slavad-ubuntu-14.04 \
    --to=slava@dubeyko.com \
    --cc=Adam.Manzanares@hgst.com \
    --cc=Cyril.Guyot@hgst.com \
    --cc=Damien.LeMoal@hgst.com \
    --cc=Vyacheslav.Dubeyko@hgst.com \
    --cc=hch@infradead.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --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.