From: Fabian Vogt <fvogt@suse.de>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-unionfs <linux-unionfs@vger.kernel.org>,
Ignaz Forster <iforster@suse.de>
Subject: Re: overlayfs does not pin underlying layers
Date: Wed, 04 Dec 2019 18:05:54 +0100 [thread overview]
Message-ID: <9499302.rauRU9GSnF@linux-e202.suse.de> (raw)
In-Reply-To: <CAJfpeguBxP7QPSr9UO6yzPpWHJ+fAckozQ823u5hPY76kqYjSQ@mail.gmail.com>
Hi,
Am Dienstag, 3. Dezember 2019, 15:19:28 CET schrieb Miklos Szeredi:
> On Tue, Dec 3, 2019 at 2:49 PM Fabian Vogt <fvogt@suse.de> wrote:
> >
> > Hi,
> >
> > I noticed that you can still unmount the lower/upper/work layers, even if
> > they're currently part of an active overlay mount. This is the case even when
> > files in the overlay mount are currently open. After unmounting, the usual
> > effects of a lazy umount can be observed, like still active loop devices.
> >
> > Is this intentional?
>
> It's a known feature. Not sure how much thought was given to this,
> but nobody took notice up till now.
>
> Do you have a good reason for wanting the underlying mounts pinned, or
> you are just surprised by this behavior? In the latter case we can
> just add a paragraph to the documentation and be done with it.
Both. It's obviously very inconsistent that it's possible to unmount something
which you still have unrestricted access to.
The specific issue we're facing here is system shutdown - if there's an active
overlayfs mount, it's not guaranteed that the unmounts happen in the right
order. Currently we work around that by adding the systemd specific
"x-systemd.requires-mounts-for=foo-lower.mount" option in /etc/fstab.
If for some reason the order is wrong, this behaviour of overlayfs might lead
to the system shutting down without the actual unmount happening properly,
as it's equivalent to "umount -l" on lower/upper FSs.
I'm not sure whether there's a scenario in which this could even lead to data
loss if something relies on umount succeeding to mean that the attached device
is unused.
Cheers,
Fabian
> Thanks,
> Miklos
next prev parent reply other threads:[~2019-12-04 17:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 13:49 overlayfs does not pin underlying layers Fabian Vogt
2019-12-03 14:19 ` Miklos Szeredi
2019-12-04 17:05 ` Fabian Vogt [this message]
2019-12-04 17:56 ` Amir Goldstein
2019-12-04 20:36 ` Miklos Szeredi
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=9499302.rauRU9GSnF@linux-e202.suse.de \
--to=fvogt@suse.de \
--cc=iforster@suse.de \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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.