Re: [QUESTION] problem about origin xattr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

So I don't see any reason to fix this.
However, if one would want to fix this, that will require at least:
1. storing a 'connectable' non-dir file handle in ORIGIN xattr
2. but still use the non-connectable file handle for index
3. in ovl_acceptable(), check if non-dir is !IS_ROOT and validate
    it with is_subdir() same as done for directories

Cheers,
Amir.

>
>
>> Hi yangerkun,
>>
>> Replying from phone so sorry for excluding list.
>> Please add list back if replying.
>>
>> This behavior is expected and sort of documented in ovl_acceptable()
>>
>> The only property required from st_ino
>> Is that it is unique together with st_dev of overlay.
>>
>> Nothing in that example breaks this requirement.
>>
>> The only semi problem is that when the old origin will be unlinked st_ino
>> of overlay inode will change.
>> That is an acceptable behavior for offline changes in overlay layers.
>>
>> Cheers,
>> Amir.
>> On Jan 31, 2018 12:36 PM, "yangerkun" <yangerkun@xxxxxxxxxx> wrote:
>>
>> Hi,
>>
>> While thinking about "origin" xattr, i find a problem which retrieval
>> methods show as below:
>>
>> $mkdir lower lower1 lower2 upper work merge
>> $touch lower1/a
>> $mount -t overlay -olowerdir=lower:lower1,upperdir=upper,workdir=work merge
>> merge
>> $echo abc > merge/a
>> $ls -li merge/a
>> Then, we can get the ino of file a equals to the ino of lower1/a.
>> $umount merge
>> $mount -t overlay -olowerdir=lower:lower2,upperdir=upper,workdir=work merge
>> merge
>> $ls -li merge/a
>>
>> The ino for file a is same as file lower1/a, while there is no file a in
>> lower and lower2. Because ovl_get_origin will get the wrong origin.
>>
>> Thanks,
>> yangerkun
--
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



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux