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

[Amir Goldstein <amir73il@gmail.com>]

On Thu, Mar 8, 2018 at 4:32 AM, yangerkun <yangerkun@huawei.com> wrote:
[...]
>>>
>>> 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.

FWIW, I don't think that removing orphan whiteouts and invalid redirects
from lower layer can cause any damage when overlayfs is mounted
(famous last words), but I agree that in principle we should avoid fsck
on layers while overlayfs is mounted.

How about this - by default, lower layers are considered read-only and
fsck -a won't modify them, only report errors. fsck -y can be used to force
fixing lower layers. Maybe another flag could be used to indicate that
lower layers could be modified.

>>
>>
>>> 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.

I see. I think that dealing with paths is wrong. pwd is not enough,
you also need
to know the mount ns root path. It's just not good to use path as an identifier.

Thanks,
Amir.