On Wed, Mar 7, 2018 at 1:14 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > 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? > Also, if we follow my suggestion above for upperdir/workdir fsck.overlay may still try to aquire I_OVL_INUSE on lowerdir with O_EXCL|O_DIRECTORY and kernel can test I_OVL_INUSE flag on lowerdir without trying to set it on mount. >> 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
