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. I guess what we could do is disable the redirect_dir by fh optimization for directories if layers were copied and always follow non-dirs by fh. That will eliminate the fallback and none of the stable inode features would miss anything. This should work well with the copied layers use case. Amir. -- 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
