Re: f2fs bug: Unable to mount big volumes in kernel 4.5

[Jaegeuk Kim <jaegeuk@kernel.org>]

On Wed, Mar 23, 2016 at 10:00:10PM +0100, Marc Lehmann wrote:
> On Wed, Mar 23, 2016 at 05:41:57PM +0100, Matthias Prager <linux@matthiasprager.de> wrote:
> > detail. Writing on a read-only fs is a no go! There usually is a reason
> > why someone mounts an filesystem read-only and f2fs should not simply
> > ignore such a flag.
> 
> Hmm, no.
> 
> Even an unusual case is enough, such as mounting it read-only for data
> recovery because the underlying device dies on writes (quite likely for
> ssds, the primary target for f2fs).
> 
> However, other linux filesystems either replay their journal on readonly
> mounts, or even *require* a replay (most have a flag to prevent that,
> but that might not help data recovery). In fact, my example above can
> relatively easily worked around using device mapper and a temporary
> snapshot volume for writes.
> 
> So, the "ro" mount flag in linux does not mean "do not write to the
> backing store", and did not have that meaning for a long time, so it's
> fine for f2fs to write even for ro mounts.
> 
> That means the correct behaviour for f2fs is to write unless "norecovery"
> has been specified, which already exists for this purpose on f2fs.

Well. IMO, we have to deal with fixing inconsistency and doing recovery
separately.

In terms of recovery, I agree that we must do it no matter how fs is mounted.
The only missing part in f2fs is that, we need to throw an error, if there is
something to recover under read-write and norecovery mount likewise ext4.

Regarding to fixing inconsistency dynamically, it seems depending on filesystems
according to how severely it can corrupt the underlying on-disk layout.
For example, I could see that btrfs conducts btrfs_recover_relocation only
when read-write mount, while doing btrfs_replay_log all the time.

Back to our cases, I think fixing superblock just depends on our policy.
Initially, I added f2fs_commit_super to recover the broken superblock
optionally, since we have no problem to mount with the alternate valid
superblock.

In the case of misaligned end address, it also doesn't need to fix it at
read-only mount, since it has nothing to do with read operations.
That is only used to check the boundary bug when writing blocks.

Lastly, when considerting RO to RW case as you pointed out, I think we need to
handle that in f2fs_remount by adding a superblock flag likewise ext4.

Let me submit some patches for them.

Thanks,

> Different behaviour would put f2fs at odds with other existing
> filesystems, which write on "ro" mounts to gain integrity.
> 
> Even better would be if there was a "force" or similar option which would
> allow me to mount filesystems with possibly bad superblock data. This
> could even be rolled into the existing "norecovery" switch, which, when
> given, could try to mount even if the superblock has (some amount of) bad
> data.
> 
> -- 
>                 The choice of a       Deliantra, the free code+content MORPG
>       -----==-     _GNU_              http://www.deliantra.net
>       ----==-- _       generation
>       ---==---(_)__  __ ____  __      Marc Lehmann
>       --==---/ / _ \/ // /\ \/ /      schmorp@schmorp.de
>       -=====/_/_//_/\_,_/ /_/\_\

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140