linux-kernel - Re: [f2fs-dev] Multidevice f2fs mount after disk rearrangement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 8 Jan 2020 04:00:38 -0800
From:   Jaegeuk Kim <jaegeuk@...nel.org>
To:     Chao Yu <yuchao0@...wei.com>
Cc:     Oleksandr Natalenko <oleksandr@...alenko.name>,
        linux-kernel@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [f2fs-dev] Multidevice f2fs mount after disk rearrangement

On 01/08, Chao Yu wrote:
> On 2020/1/7 2:40, Oleksandr Natalenko via Linux-f2fs-devel wrote:
> > Hi.
> > 
> > On 06.01.2020 19:34, Jaegeuk Kim wrote:
> >> Thank you for investigating this ahead of me. :) Yes, the device list 
> >> is stored
> >> in superblock, so hacking it manually should work.
> >>
> >> Let me think about a tool to tune that.
> > 
> > Thank you both for the replies.
> > 
> > IIUC, tune.f2fs is not there yet. I saw a submission, but I do not see 
> > it as accepted, right?
> > 
> > Having this in tune.f2fs would be fine (assuming the assertion is 
> > replaced with some meaningful hint message), but wouldn't it be more 
> > convenient for an ordinary user to have implemented something like:
> > 
> > # mount -t f2fs /dev/sdb -o nextdev=/dev/sdc /mnt/fs
> 
> Hmm... sounds reasonable, however, the risk is obvious, if we mount with wrong
> primary device, filesystem can be aware that with metadata sanity check, if we
> mount with wrong secondary/... devices by mistake (or intentionally, people
> may think filesystem should be aware illegal parameters....), filesystem won't
> be aware of that, then metadata/data will be inconsistent...
> 
> Although that may also happen when we use tunesb.f2fs, but fsck.f2fs can be
> followed to verify the modification of tunesb.f2fs, that would be much safer.
> 
> So I suggest we can do that in tools first, maybe implement nextdev mount option
> if we have added metadata in secondary/... device.

+1, it'd be risky for user to give the device list whenever mounting the
filesystem. There'll be subtle corner cases where f2fs needs to deal with
given ambiguous sets between superblock and mount option.

> 
> Thanks,
> 
> > 
> > Hm?
> >