On Thu, Dec 14, 2017 at 5:29 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Thu, Dec 14, 2017 at 5:48 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> On Thu, Dec 14, 2017 at 4:18 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >>> On Thu, Dec 14, 2017 at 5:10 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > [...] >>> Yes :) Docker uses tar alright. >>> But for example "origin" xattr cannot be exported as is to a portable format. >>> Need to decode file handles during export and change them to "redirect" >>> for directories and possible to "redirect" for files as well, that >>> would be converted >>> back to "origin" on import. >> >> Is it worth preserving origin for non-hardlinks? Same story as "cp >> -a", inode numbers will change, so there doesn't appear to be a reason >> to preserve the connection between origin and the copied up file. > > Besides metacopy, no reason. > >> >>> Exporting index is a challenge for the same reason and also because tar can >>> break hardlinks on extract. Probably index should be rebuilt from scratch on >>> import, based on "redirect". >> >> Yes, hard links need special handling, so will metacopy. Might be >> worth adding "redirect" to hard links and metacopy to make this issue >> less of a problem. >> > > Do you mean add it now in kernel? hmm, that's just another thing that > can become inconsistent, so I don't see the immediate value. The immediate value is that no need for a special pack/unpack tool for transferring the overlay "image". > > Which reminds me, you did not provide feedback to the patch I posted > to detect duplicate redirect dir use case: > > https://marc.info/?l=linux-unionfs&m=151126880100432&w=2 > > Do you consider this a bug that should be detected by overlayfs > as patch proposed or leave it to be detected only when enabling > opt-in directory indexing (named verify=on in current WIP patches)? > > Also waiting for your feedback about merging the duplicate redirect dir > test case to xfstests: > https://marc.info/?l=fstests&m=151149994629687&w=2 > > Bug or not bug? Hmm... I'd lean towards non-bug. That "offline modification is allowed" rule should point out caveats when messing with overlay specific attributes (opaque, whiteout, redirect, etc). Obviously having two redirects pointing to the same underlying dir is going to result in inconsistencies. We can get away with it without constant ino, but I don't think it makes sense to allow that construct. 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
