On Mon, Nov 9, 2020 at 10:53 AM Giuseppe Scrivano <gscrivan@xxxxxxxxxx> 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. > > 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? > My bad. I always confuse sync -f as fsync(). Sorry for the noise, Amir.
