Re: [PATCH v4] ovl: whiteout inode sharing

[Amir Goldstein <amir73il@gmail.com>]

On Tue, Apr 28, 2020 at 4:32 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Tue, Apr 28, 2020 at 3:16 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Tue, Apr 28, 2020 at 3:21 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> > > And I don't really see a reason to disable whiteout hard links.  What scenario
> > > would that be useful in?
> >
> > I have a vague memory of e2fsck excessive memory consumption
> > in face of many hardlinks created by rsync backups.
> > Now I suppose it was a function of number of files with nlink > 1 and not
> > a function of nlink itself and could be a non issue for a long time, but I am
> > just being careful about introducing non-standard setups which may end up
> > exposing filesystem corner case bugs (near the edge of s_max_links).
> > Yeh that is very defensive, so I don't mind ignoring that concern and addressing
> > it in case somebody shouts.
>
> Right, and even if such a corner case bug exists, it's still primarily
> a bug in the underlying filesystem and should be fixed there. A
> workaround in overlay would only make sense if for some reason the
> primary fix is difficult or impossible.
>

Sure.

> > > +fallback:
> > > +       whiteout = ofs->whiteout;
> > > +       ofs->whiteout = NULL;
> > > +success:
> >
> > This label is a bit strange, but fine.
>
> Agreed, changed to "out:"
>

I meant no reason to have goto label when you can just return whiteout,
but it's fine either way.

Thanks,
Amir.