On Wed, Jun 21, 2017 at 10:49 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Wed, Jun 21, 2017 at 11:45 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> On Wed, Jun 21, 2017 at 10:38 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >>> On Wed, Jun 21, 2017 at 10:20 AM, Miklos Szeredi <miklos@xxxxxxxxxx> 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 -- 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
