[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160524085236.GB8121@infradead.org>
Date: Tue, 24 May 2016 01:52:36 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Viacheslav Dubeyko <slava@...eyko.com>
Cc: Christoph Hellwig <hch@...radead.org>,
Jaegeuk Kim <jaegeuk@...nel.org>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net,
Vyacheslav.Dubeyko@...t.com, Cyril.Guyot@...t.com,
Adam.Manzanares@...t.com, Damien.LeMoal@...t.com
Subject: Re: [PATCH] f2fs: introduce on-disk layout version checking
functionality
On Mon, May 23, 2016 at 01:08:05PM -0700, Viacheslav Dubeyko wrote:
> I think that it's some confusion. I didn't introduce any new fields in
> struct f2fs_super_block. The "major_ver" and "minor_ver" fields exist in
> F2FS superblock from the beginning of this file system implementation.
> The content of these two fields are defined during mkfs phase. The
> f2fs_format.c contains such code in f2fs_prepare_super_block():
They exists, but the kernel so far never checked them, and despite
that the feature checking works fine worth other f2fs features.
> Current version in VERSION file is 1.6.1. So, historically F2FS is using
> version of on-disk layout. The suggested patch simply introduces the
> threshold value F2FS_MAX_SUPP_MAJOR_VERSION with the purpose to refuse
> the mount operation for the case of unsupported version of on-disk
> layout.
While I've never seen an actual piece of documentation for the fields it
seems so far they just document the version of mkfs used to create
the file system. Suddenly overloading them with semantics is just
going to create problems.
> First of all, it needs to distinguish two different points. First point,
> we need to increase the on-disk layout version because we are going to
> change on-disk layout in the way that old (current) driver will not
> support.
That's exactly what most file systems use feature flags for.
Powered by blists - more mailing lists