From: Fabian Vogt <fvogt@suse.de>
To: linux-unionfs <linux-unionfs@vger.kernel.org>
Cc: iforster@suse.de
Subject: overlayfs does not pin underlying layers
Date: Tue, 03 Dec 2019 14:49:50 +0100 [thread overview]
Message-ID: <7817498.QaoxCVBQX0@linux-e202.suse.de> (raw)
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? From a quick look, for open files this might be a side
effect of using open_with_fake_path, but just getting a reference to the paths
in ovl_mount_dir and preventing unmounting for the duration of the overlay
mount would cover that as well AFAICT.
Thanks,
Fabian
---< demo script >---
#!/bin/bash
set -euxo pipefail
tmpdir=$(mktemp -d)
trap "rm -rf $tmpdir" EXIT
mkdir ${tmpdir}/{lower,upper,work,mount}
# Create ext4 fs, mount as lower
dd if=/dev/zero of=${tmpdir}/fs.img bs=1M count=10
mkfs.ext4 -q ${tmpdir}/fs.img
mount ${tmpdir}/fs.img ${tmpdir}/lower
# Create a file
echo "This is in lower" > ${tmpdir}/lower/lowerfile
# Mount overlayfs
mount -t overlay overlay ${tmpdir}/mount -o lowerdir=${tmpdir}/lower,workdir=${tmpdir}/work,upperdir=${tmpdir}/upper
# Open the file and print its contentghzogo8ugz312 iutv123u1
exec 3<${tmpdir}/mount/lowerfile
cat <&3
# Umount the lower fs
umount ${tmpdir}/lower && echo "Lower successfully unmounted"
# Show that the overlay mount is still there
mountpoint -q ${tmpdir}/lower || echo "Lower is not mounted anymore"
mountpoint -q ${tmpdir}/mount && echo "Overlay still mounted"
cat ${tmpdir}/mount/lowerfile
# Clean up
exec 3<&-
umount ${tmpdir}/mount
next reply other threads:[~2019-12-03 13:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 13:49 Fabian Vogt [this message]
2019-12-03 14:19 ` overlayfs does not pin underlying layers Miklos Szeredi
2019-12-04 17:05 ` Fabian Vogt
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=7817498.QaoxCVBQX0@linux-e202.suse.de \
--to=fvogt@suse.de \
--cc=iforster@suse.de \
--cc=linux-unionfs@vger.kernel.org \
/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.