All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Sargun Dhillon <sargun@sargun.me>
Cc: overlayfs <linux-unionfs@vger.kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Amir Goldstein <amir73il@gmail.com>,
	Giuseppe Scrivano <gscrivan@redhat.com>,
	Daniel J Walsh <dwalsh@redhat.com>
Subject: Re: [PATCH v7] overlayfs: Provide a mount option "volatile" to skip sync
Date: Fri, 6 Nov 2020 14:03:25 -0500	[thread overview]
Message-ID: <20201106190325.GB1445528@redhat.com> (raw)
In-Reply-To: <CAMp4zn9dF-umZF-LP=f6qWekyupsXTB6B8CeH6km7=9oVYV+NA@mail.gmail.com>

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.

Intial version of patches had both the volatile modes implemented.
Later we dropped one because it was not clear who wants this
second mode. If this is something which is useful for you, it
can possibly be introduced.

Thanks
Vivek


  parent reply	other threads:[~2020-11-06 19:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-31 18:15 [PATCH v7] overlayfs: Provide a mount option "volatile" to skip sync Vivek Goyal
2020-09-01  8:22 ` Amir Goldstein
2020-09-01 13:14   ` Vivek Goyal
2020-11-06 17:58 ` Sargun Dhillon
2020-11-06 19:00   ` Amir Goldstein
2020-11-06 19:20     ` Vivek Goyal
2020-11-09 17:22     ` Vivek Goyal
2020-11-09 17:25       ` Sargun Dhillon
2020-11-09 19:39         ` Amir Goldstein
2020-11-09 20:24           ` Vivek Goyal
2020-11-06 19:03   ` Vivek Goyal [this message]
2020-11-06 19:42     ` Giuseppe Scrivano
2020-11-07  9:35       ` Amir Goldstein
2020-11-07 11:52         ` Sargun Dhillon
2020-11-09 20:40           ` Vivek Goyal
2020-11-09  8:53         ` Giuseppe Scrivano
2020-11-09 10:10           ` Amir Goldstein
2020-11-09 16:36         ` Vivek Goyal
2020-11-09 17:09         ` Vivek Goyal
2020-11-09 17:20           ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201106190325.GB1445528@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=dwalsh@redhat.com \
    --cc=gscrivan@redhat.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=sargun@sargun.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.