Re: [fsck.overlay RFC PATCH] overlay: add fsck utility

[yangerkun <yangerkun@huawei.com>]

On 3/7/2018 7:14 PM, Amir Goldstein wrote:
> On Wed, Mar 7, 2018 at 11:25 AM, yangerkun <yangerkun@huawei.com> 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@huawei.com> 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.