On 3/7/2018 7:14 PM, Amir Goldstein 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?
A orphan whiteout and invalid redirect in lower layer will be removed
automatic or ask user.
Since we cannot change anything for lower layer when overlay has been
mounted, so we need run fsck.overlay first before mount to ensure
consistency.
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.
We can use the parameters passed in by fsck.overlay and current working
directory to construct absolute path for lower layers and upper layer;
but when we want to get the information about mounted overlayfs through
mountinfo, we cannot construct the absolute path of lower layer and
upper layer without the pwd when we mount an overlayfs.
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 for your advise, i will think how to realize.
Thanks,
Amir.
.
Thanks,
yangerkun.
--
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
