Re: [QUESTION] problem about origin xattr

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

 



On Thu, Feb 1, 2018 at 5:57 AM, yangerkun <yangerkun@xxxxxxxxxx> wrote:
>
>
[...]
>>>
>>>
>>> Like directories, we'd only need to set REDIRECT on rename.
>>>
>>> So when file has METACOPY, but not REDIRECT, we just fall through to
>>> next layer below one we are currently operating on.  If we find
>>> METACOPY there, we just continue looking until we find a file
>>> containing the data.
>>>
>>> When we rename or hardlink a file with METACOPY, we add REDIRECT.
>>>
>>> If file has METACOPY and REDIRECT, we follow REDIRECT to find a file
>>> on the next level and keep iterating until we have the one with the
>>> data.
>>>
>>> ORIGIN would not be used in this case.  We might be able to use ORIGIN
>>> for some kind of verification, like we do for directories.   Amir has
>>> a better idea, I think.
>>>
>>> Another way to think about it is: METACOPY is the opposite of OPAQUE.
>>> For directories the default is "metacopy" and contents are merged.
>>> For files the default is "opaque" and content is not merged.  METACOPY
>>> turns that around and enables "merging" of data from a lower layer.
>>> I could even imagine real merging of data, but it's unlikely to be
>>> worth the effort, clone is much better for that; METACOPY is just a
>>> very restricted (and so much simpler) way of merging data.
>>
>>
>> Ok, thanks. I am beginning to understand it better now.
>
>
> Does there any problem using REDIRECT to confirm the file with METACOPY? If
> there is a rename of the REDIRECT file in lower while overlay offline,
> METACOPY will get no file?
>
> I prefer suggestion of Amir, use subtree_check like nfs to make sure the
> origin dentry existing in subdir of the lower layer.
>

This preference depends on the use case.
For your use case that is sensitive to offline lower renames, as well as my
snapshot use case, the chosen behavior could be to follow ORIGIN and fix
REDIRECT to match it, as I implemented here:
https://github.com/amir73il/linux/commits/ovl-redirect-origin

For the default use case where lower content is not expected to change,
but layers could be copied/migrated, relying on file handles is a problem,
so the default would be to follow REDIRECT and verify/fix ORIGIN to match it.

When Vivek implements METACOPY using the same code path used
for directories, the work I did for redirect_dir=origin could be applied
also to METACOPY, given that ORIGIN is changed to use connectable
file handles in that case.

Cheers,
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



[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