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

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

 



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.

I guess what we could do is disable the redirect_dir by fh optimization
for directories if layers were copied and always follow non-dirs by fh.
That will eliminate the fallback and none of the stable inode features
would miss anything.
This should work well with the copied layers use case.

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