On Wed, Apr 21, 2010 at 10:52:21AM +0100, Jamie Lokier wrote: > Miklos Szeredi wrote: > > Detecting mount points is best done by comparing st_dev for the parent > > directory with st_dev of the child. This is much simpler than parsing > > /proc/mounts and will work for bind mounts as well as union mounts. > > Sorry, no: That does not work for bind mounts. Both layers can have > the same st_dev. Nor does O_NOFOLLOW stop traversal in the middle of > a path, there is no handy O_NOCROSSMOUNTS, and no st_mode flag or > d_type to say it's a bind mount. Bind mounts are really a big pain > for i_nlink+inotify name counting. > > Besides, calling stat() on every entry in a large directory to check > st_ino can be orders of magnitude slower than readdir() on a large > directory - especially with a cold cache. It is quicker, but much > more complicated, to parse /proc/mounts and apply arcane rules to find > the exceptions. > > Can a union mount overlap two parts of the same filesystem? No. Each layer must be a separate file system, the bottom must be read-only, the top must be writable, and they must be unioned at their mount points. > > I think there's no question that union mounts might break apps (POSIX > > or not). But I think there's hope that they are few and can easily be > > fixed. > > I agree, and union moint is a very useful feature that's worth > breaking a few apps for :-) > > I'm curious if there's a clear way to go about it in this case, or > if it'll involve a certain amount of pattern recognition in /proc/mounts. All it takes is looking for the "union" string in the mount options. > Basically I'm wondering if it's been thought about already. Not as much as it deserves. :) Do you have any thoughts about better solutions? Something to keep in mind is that most of the app issues are already present with bind mounts. In many cases, if an app doesn't work with union mounts, it's also not going to work with bind mounts. I think you have a good point that we could use a more straightforward way to say, "Hey, you can't use the normal st_dev/st_ino rules right now..." -VAL -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
