On Fri, Dec 15, 2017 at 03:18:58PM +0100, Miklos Szeredi wrote: > 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". Hi Miklos, So idea is that I should use use REDIRECT xattr instead of ORIGIN for metacopy. I guess it should work for atleast metacopy feature. Just that order of lower dirs during mount will not be detected and IIUC, we might end up doing a copy up of wrong file. Vivek -- 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