Le 10/03/2015 16:53, Lennart Poettering a écrit :
On Mon, 09.03.15 11:27, Didier Roche (didro...@ubuntu.com) wrote:
However, some file systems (seems overlayfs at least) would report a
major(st_dev) as 0 on directories and not on files. The current
path_is_mount_point() fallback logic would thus reports that every files is
a mount point. The enclosed patch introduces a second fallback to read
/proc/mounts, and ensures there is no shadowing by later mounting of parent
directories. This slower path is only used when the 2 first methods failed
to determine with assurance if the path is a mount point or not.
Humppf, I am not convinced this is really a good idea.
I mean, we use name_to_handle_at() precisely for the reason that we
don't want to parse /proc/self/mountinfo, since that is really
cumbersome if you want to do it properly, given that mounts can
obstruct other mounts and symlink/realpath complexity and stuff.
Note that the st_dev thing is the traditional way to detect whether
one crosses a file system boundary. It's used for this by tools like
cp, find, .... We slightly enhance this by using name_to_handle_at(),
so that we can also detect bind mounts from file systems onto
themselves. Now, if overlayfs breaks the same file system logic of all
other tools, I am not convinced that systemd should not be broken by
it too.. It sounds surprising that we should work around this in
systemd, but not in all other tools.
Or to turn this around: instead of patching systemd the better idea
would probably be to teach overlayfs name_to_handle_at() support, so
that there's a way to detect the mount id from such a file system in a
safe way.
Hmm, where precisely did you run into problems with this?
The context is bug
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1411140, where
systemd-machine-id-commit unit is entering in failed state (the binary
handles gracefully the fact that it can't unmount the file) on a default
ubuntu live system (which is a squashfs/overlayfs system).
This means that a live starts in degraded mode when booted with systemd
(mostly a cosmetic issue for sure, but we would rather avoid it). Seeing
that the logic to check if a path is a mount point already had a
fallback (the traditional way), I thought another one would be
acceptable, but I understand that you were ok with the first one as it's
the general way tools are detecting that case. I thought as Ryan told
that glib was going to a similar approach that this fallback would be a
little bit more considered as standard…
I agree that the best way would be to get the kernel fixed for this, I
talked to our kernel team and it doesn't seem we would gain traction on
having name_to_handle_at() support on overlayfs, so quite stuck on this
for now. Maybe there is a better option?
Cheers,
Didier
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
