On Fri, Oct 30, 2020 at 2:20 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Fri, Oct 30, 2020 at 2:05 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >
> > On Mon, Jul 13, 2020 at 4:20 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> > >
> > > Following non-dir origin can result in some bugs when underlying layers
> > > are edited offline.
> >
> > Sorry, lost track. What bugs this results in?
>
> Frankly, not in a reported bug, but a theoretical one, so feel free to take
> it or leave it. I tried to rationalize it in the cover letter [1].
>
> The bug is that you can have an upper inode with wrong origin
> lower inode when re-creating lower fs in a way that rewrites the
> unique file handle history of the lower fs. This can result in two non-hardlinks
> pointing at the same origin and possibly worse.
>
> Commit a888db310195 ("ovl: fix regression with re-formatted lower squashfs")
> solved this problem for re-created lower squashfs by not following
> origin in the
> case of lower fs with null uuid.
>
> The case of lower fs with non-null uuid you said was less interesting because
> re-creating lower would result in a new uuid and therefore origin will not
> be followed to the wrong inode.
>
> However, the uuid=off use case [2] tells us that lower fs with uuid can in-fact
> be re-created with the same uuid when a prototype image is being cloned
> and modified.
>
> The uuid=off feature was proposed because Virtuozzo change the uuid
> of lower image after it has been cloned. But other users may not follow
> this practice. As a matter of fact xfs has mount option nouuid exactly for
> this case (mount a cloned block device as well as the origin).
>
> Long story short, I just thought it would be nice for users to have a way to
> opt-out of any sort of decoding origin when they want "legacy" overlay
> functionality in case we have any more latent origin related bugs.
Okay, let's just postpone this until a real issue turns up.
Thanks,
Miklos
