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. Thanks, Miklos -- 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
