On Wed, Mar 7, 2018 at 11:25 AM, yangerkun <yangerkun@xxxxxxxxxx> wrote: > > > On 11/18/2017 1:13 AM, Amir Goldstein wrote: >> >> [adding fstests in CC with full patch inline to collect wisdom from >> other fs developers] >> >> On Fri, Nov 17, 2017 at 7:49 AM, zhangyi (F) <yi.zhang@xxxxxxxxxx> wrote: >>> >>> Hi, > > [...] >>> >>> >>> Todo >>> ==== >>> >>> 1. Overlay filesystem mounted check. Prevent fscking when overlay is >>> online. Now, We cannot distinguish mounted directories if overlayfs was >>> mounted with relative path. >> >> >> This should be handled by kernel. >> We now already grab an advisory exclusive I_OVL_INUSE lock on both >> upperdir and workdir. >> fsck.overlay can try to open upperdir/workdir with O_EXCL|O_DIRECTORY >> and kernel should fail this open if overlayfs is holding the I_OVL_INUSE. >> Read the man page section on O_EXCL and block device. This is how >> e2fsck and friends get exclusive access w.r.t mount. >> > > In fsck.overlay, lower layer file/dir may be modified with there is not > I_OVL_INUSE in lower layer, but we cannot check does lower layer mounted > with I_OVL_INUSE. > Can you list the possible modifications the fsck.overlay can do on lower layer? What exactly are we trying to protect from? > Maybe we need adopt another way? How about store pwd in ofs.config when we > mount the overlay. > I don't understand what that means. Instead of relying on the partial information available in /proc/<pid>/mountinfo we can export more interesting information from kernel per overlayfs mount, see for example the information available at /proc/fs/ext4/<blockdev>/ For example, we can expose "layers" information, including the file handle of all layers root dir, so fsck.overlay can figure out if any upper/lower dir are in-use without needing to resolve paths. There is probably other interesting information from ofs.config that can be exposed this way. Instead of <blockdev> (in the ext4 case) the key would have to be the overlayfs anonymous dev, which can be read by stat(2) on any overlay directory. Thanks, Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
