Re: [PATCH v7] overlayfs: Provide a mount option "volatile" to skip sync

[Giuseppe Scrivano <gscrivan@redhat.com>]

Vivek Goyal <vgoyal@redhat.com> writes:

> On Fri, Nov 06, 2020 at 09:58:39AM -0800, Sargun Dhillon wrote:
>
> [..]
>> There is some slightly confusing behaviour here [I realize this
>> behaviour is as intended]:
>> 
>> (root) ~ # mount -t overlay -o
>> volatile,index=off,lowerdir=/root/lowerdir,upperdir=/root/upperdir,workdir=/root/workdir
>> none /mnt/foo
>> (root) ~ # umount /mnt/foo
>> (root) ~ # mount -t overlay -o
>> volatile,index=off,lowerdir=/root/lowerdir,upperdir=/root/upperdir,workdir=/root/workdir
>> none /mnt/foo
>> mount: /mnt/foo: wrong fs type, bad option, bad superblock on none,
>> missing codepage or helper program, or other error.
>> 
>> From my understanding, the dirty flag should only be a problem if the
>> existing overlayfs is unmounted uncleanly. Docker does
>> this (mount, and re-mounts) during startup time because it writes some
>> files to the overlayfs. I think that we should harden
>> the volatile check slightly, and make it so that within the same boot,
>> it's not a problem, and having to have the user clear
>> the workdir every time is a pain. In addition, the semantics of the
>> volatile patch itself do not appear to be such that they
>> would break mounts during the same boot / mount of upperdir -- as
>> overlayfs does not defer any writes in itself, and it's
>> only that it's short-circuiting writes to the upperdir.
>
> umount does a sync normally and with "volatile" overlayfs skips that
> sync. So a successful unmount does not mean that file got synced
> to backing store. It is possible, after umount, system crashed
> and after reboot, user tried to mount upper which is corrupted
> now and overlay will not detect it.
>
> You seem to be asking for an alternate option where we disable
> fsync() but not syncfs. In that case sync on umount will still
> be done. And that means a successful umount should mean upper
> is fine and it could automatically remove incomapt dir upon
> umount.

could this be handled in user space?  It should still be possible to do
the equivalent of:

# sync -f /root/upperdir
# rm -rf /root/workdir/incompat/volatile

Regards,
Giuseppe