On Sat, Nov 07, 2020 at 11:35:04AM +0200, Amir Goldstein wrote: > On Fri, Nov 6, 2020 at 9:43 PM Giuseppe Scrivano <gscrivan@xxxxxxxxxx> wrote: > > > > Vivek Goyal <vgoyal@xxxxxxxxxx> 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 > > > > FWIW, the sync -f command above is > 1. Not needed when re-mounting overlayfs as volatile > 2. Not enough when re-mounting overlayfs as non-volatile > > In the latter case, a full sync (no -f) is required. Hi Amir, I am wondering why "sync -f upper/" is not sufficient and why full sync is required. Vivek
