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? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel