On Wed, Apr 19, 2017 at 6:21 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Tue, Apr 18, 2017 at 8:57 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> On Tue, Apr 18, 2017 at 9:32 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >>> On Tue, Apr 18, 2017 at 05:05:12PM +0300, Amir Goldstein wrote: >>> >>> [..] >>>> > (This ovl_lookup() logic has become really twisted now. I wished it was >>>> > little easier to read.) >>>> > >>>> >>>> Me too. IMO, most of the complexity is in the fallbacks from redirect >>>> by fh to full path to relative path. Eliminating some of these fallbacks >>>> and maybe having separate lookup op per mode, may simplify the code. >>> >>> In general, why are we falling back to path based lookup. If lower dirs >>> were copied or something else, that's a configuration error and overlayfs >>> will have undefined behavior? >>> >> >> Heh, I just sent out a summary of what happens when lower dirs are copied. >> The fallback is needed because when lower/upper dirs are copied >> (which is a perfectly valid practice), the xattr are copied with them. >> So the fallback is needed because ovl_lookup() find the fh on upper dir >> and tries to follow it only to realize that it is stale - then it assumes that >> layers were copied and resorts to path lookup. >> >> My point earlier is that I wish to move this "was I copied?" test to mount >> time instead of doing it on every lookup. But then user won't be able >> to enjoy all the benefits of stable inodes after layers were copied, so >> this is not ideal. > > How so? Nobody is expecting the copy to have the same inode numbers > as the original. > > So it's fine if the relation to the original lower layer file is > broken, we don't care about that anymore. Except for the hard link > case, but that relation can be preserved in the reverse mapping. > I was addressing Vivek's concern about the complexity of the "fallback from fh to path" code. I managed to get the following use case wrong: - 2 or more lower layers that have some dir redirects by path - upper layer that now creates redirect_fh After following from upper to lower1 by fh, I failed to follow by path to lower2. So I contemplated detecting this mixed mode at mount time and disabling redirect_fh. Nevermind, I'll just fix the fallback in mid layers case. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
