Re: [RFC][PATCH 03/13] ovl: lookup redirect by file handle

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

 



On Wed, Apr 19, 2017 at 6:21 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Tue, Apr 18, 2017 at 8:57 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>> On Tue, Apr 18, 2017 at 9:32 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
>>> On Tue, Apr 18, 2017 at 05:05:12PM +0300, Amir Goldstein wrote:
>>>
>>> [..]
>>>> > (This ovl_lookup() logic has become really twisted now. I wished it was
>>>> >  little easier to read.)
>>>> >
>>>>
>>>> Me too. IMO, most of the complexity is in the fallbacks from redirect
>>>> by fh to full path to relative path. Eliminating some of these fallbacks
>>>> and maybe having separate lookup op per mode, may simplify the code.
>>>
>>> In general, why are we falling back to path based lookup. If lower dirs
>>> were copied or something else, that's a configuration error and overlayfs
>>> will have undefined behavior?
>>>
>>
>> Heh, I just sent out a summary of what happens when lower dirs are copied.
>> The fallback is needed because when lower/upper dirs are copied
>> (which is a perfectly valid practice), the xattr are copied with them.
>> So the fallback is needed because ovl_lookup() find the fh on upper dir
>> and tries to follow it only to realize that it is stale - then it assumes that
>> layers were copied and resorts to path lookup.
>>
>> My point earlier is that I wish to move this "was I copied?" test to mount
>> time instead of doing it on every lookup. But then user won't be able
>> to enjoy all the benefits of stable inodes after layers were copied, so
>> this is not ideal.
>
> How so?  Nobody is expecting the copy to have the same inode numbers
> as the original.
>
> So it's fine if the relation to the original lower layer file is
> broken, we don't care about that anymore.  Except for the hard link
> case, but that relation can be preserved in the reverse mapping.
>

I was addressing Vivek's concern about the complexity of the
"fallback from fh to path" code.
I managed to get the following use case wrong:
- 2 or more lower layers that have some dir redirects by path
- upper layer that now creates redirect_fh
After following from upper to lower1 by fh, I failed to follow by
path to lower2.

So I contemplated detecting this mixed mode at mount time
and disabling redirect_fh.

Nevermind, I'll just fix the fallback in mid layers case.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux