[...] >> >> Besides that I am still worried about corners we missed in setup of >> metacopy=on,index=off. >> >> I may be confused about whether lower with nlink=1 with index=off >> after metacopy up uses upper st_ino and hashed by upper inode? >> Need to understand whether the "hashed by" state is consistent with >> metacopy=on,index=off in all cases. > > metacopy=on, index=off should not change inode number reporting. For > the case of nlink=1 and index=off, st_ino of lower is reported and > metacopy=on/off does not matter at all. Similarly, ovl_hash_bylower() > remains untouched due to metacopy. So for the case of nlink=1, index=off, > inode should still be hashed using lower inode number. > > Only thing metacopy feature changes in stat() is st_blocks. It should > not impact st_ino or st_dev reporting at all. > I did not articulate my concern correctly. The problem is not with index=off, but with !ovl_can_decode_fh() which implies index=off, but does not imply metacopy=off. With !ovl_can_decode_fh(), lower cannot be followed by ORIGIN and therefore cannot have CONST_INO, but with METACOPY lower is followed... only until METACOPY xattr is removed and then lower is no longer followed. The solution is probably to fix (or at least audit) ovl_hash_bylower() to recognize this case and treat those lowers as broken hardlinks even though they have nlink=1, so METACOPY won't hash by lower and won't use lower st_ino. As I wrote, I am not sure there are problems here, but would like to make sure that there aren't any problems. Thanks, 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
