Re: [PATCH v2 01/17] ovl: document NFS export

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

 



On Fri, Jan 12, 2018 at 5:49 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Fri, Jan 12, 2018 at 4:43 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>> On Thu, Jan 11, 2018 at 5:26 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
>>> When decoding an upper dir, the decoded upper path is the same path as
>>> the overlay path, so we lookup same path in overlay.
>>>
>>> When decoding a lower dir from layer 1, every ancestor is either still lower
>>> (and therefore not renamed) or been copied up and indexed by lower inode,
>>> so we can use index to know the path of every ancestor in overlay (or if it
>>> has been removed).
>>>
>>> When decoding a lower dir from layer 2, there may be an ancestor in layer 2
>>> covered by whiteout in layer 1 and redirected from another directory in layer 1.
>>> In that case, we have no information in index to reconstruct the overlay path
>>> from the connected layer 2 directory, hence, we cannot decode a connected
>>> overlay directory from dir file handle encoded from layer 2.
>>
>> Now I understand: we are missing the back pointer from layer2 to
>> layer1 that the index provides us when going from lower to upper.
>>
>> However, this is only needed if we end up below a redirecting layer.
>> So we could limit copy-up to these cases.  It doesn't seem hard to
>> keep track of highest layer that had a redirect in each overlay
>> dentry, and when ending up on a layer below that, mark the overlay
>> dentry COPY_UP_FOR_ENCODE.  This information is constant, since lower
>> layers are immutable, so no worries there.

Right.

>> Can postpone this to a
>> later version, but the takeaway is that we need to mark the fh to
>> indicate if it's a merge upper or not.
>

This I did not get.
The fh is marked upper or not.
If it is upper, we get the real upper path and lookup that path in overlay.
Whether upper is merge or not, overlay lookup will find out.

What am I missing?


> And BTW, we need to copy up only the directory that has the redirect,
> since that's where we are missing the mapping in the lower layers.
> Below that in the tree, we are fine, until we come across another
> redirect, and so on...
>

So actually, I can use OVL_RENAMED flag from patch 8/23
and implement ovl_copy_up_renamed_parent() on encode
This will actually also cover the case of dir in layer1 that has a
non-indexed redirected upper parent.

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