> 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. Thanks for the clarification. Why wouldn't a syncfs on the upper directory be enough to ensure files are persisted and safe to reuse after a crash? Regards, Giuseppe
