Re: [PATCH v3 5/5] ovl: consistent st_ino/d_ino

Miklos Szeredi
2017-06-21T08:53:04Z

On Wed, Jun 21, 2017 at 10:49 AM, Amir Goldstein <amir73il@gmail.com> wrote:
> On Wed, Jun 21, 2017 at 11:45 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> On Wed, Jun 21, 2017 at 10:38 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>> On Wed, Jun 21, 2017 at 10:20 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>>
>>>> Right. The problem is when dir becomes impure due to rename between
>>>> two getdents(2) calls. We can't call ovl_dir_reset() because the
>>>> offset is not zero. We could do a "cache with head cut off" starting
>>>> from the current offset in the dir and finish with that. Yeah, it's
>>>> probably less complexity than trying to intercept the actor...
>>>
>>> On the other hand, we'll need to accommodate the native directory
>>> indexing (i.e. seekdir(3) hell) in the cache, which is going to add to
>>> complexity. Ugh.
>>
>> Another idea: we are allowed to omit directory entries added after
>> the opendir/rewinddir. So if there was a simple way to filter out
>> newly added entries which have origin then we are fine.
>>
>
> Then how about this: implement an actor that ONLY looks in
> overlay dcache for the entries.
> If entry is in dcache then can take inode number from overlay
> inode.
> If entry is not in dcache AND the file was just moved into dir
> (quite unlinkely) then write off d_ino as a transient inconsistency.

Note: in theory the "just moved into dir" can be two weeks before. In
practice it's unlikely that two calls of getdents(2) will be so far
apart in time.

Still, this feels a bit too hacky.

Thanks,
Miklos