On Wed, Jan 31, 2018 at 4:58 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Wed, Jan 31, 2018 at 5:46 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> On Wed, Jan 31, 2018 at 05:38:45PM +0200, Amir Goldstein wrote: >>> On Wed, Jan 31, 2018 at 5:20 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >>> > On Wed, Jan 31, 2018 at 03:57:12PM +0200, Amir Goldstein wrote: >>> > >>> > ORIGIN behavior is little unintuitive though. Despite the fact that file >>> > is not searchable through lower, it is visible through decoding of file >>> > handle and it is atleast non-intuitive. >>> > >>> >>> Maybe not intuitive at first glance, but try again: >>> >>> The only thing we *need* from underlying fs is to provide us with a unique >>> and persistent inode number we can use for the overlay object. >>> >>> Even if the inode number we get from underlying fs is not in any of the >>> layers, it is still a viable inode number we can use in overlay coupled >>> with overlay unique st_dev, to create a system wide unique st_dev;st_ino >>> tuple. >> >> As long as we use only inode number, it probably is still fine. >> >> But I look at ORIGIN as a generic infrastructure which other features can >> make use of it. For example, metacopy is using it to copy up file later. >> And there it will be non-intuitive that a file is not in any of the >> lower, still ORIGIN was decoded and file was copied up. It can come >> as a surprise to user. Atleast I was surprised when I ran into this >> while testing the feature. How about using REDIRECT for metacopy origin? Keeping ORIGIN only for inode, also meaning ORIGIN is only ever used on upper layer, never on middle layers. 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
