On Tue, Apr 28, 2020 at 4:32 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, Apr 28, 2020 at 3:16 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > On Tue, Apr 28, 2020 at 3:21 PM Miklos Szeredi <miklos@xxxxxxxxxx> 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.
