On Wed, Dec 5, 2018 at 7:06 PM Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: > > On Dec 05 2018, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, Dec 4, 2018 at 8:04 PM Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: > >> > >> On Dec 04 2018, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > >> > The GETATTR requests are due atime invalidations. > >> > >> Could you elaborate? I'm not sure what that means here. What is an atime > >> invalidation? > > > > POSIX states that on read(2), readdir(3), readlink(2), etc, the > > st_atime of the file/directory/symlink needs to be updated to the > > current time. So when e.g. a READ request is sent, fuse will > > invalidate the cache in the belief that the server will update the > > atime. In this casea subsequent stat(2) will find the invalid cache > > and will issue a GETATTR to the server, which will reply with an > > updated atime value. > > This sounds like it should not happen when writeback is active, because > in that case userspace doesn't know the right attributes either. > > Or is there special code that only prevents invalidation if there > already is dirty data for the inode? If so, is there a reason for not > updating atime in the kernel whenever writeback is active? Atime handling is a mess anyway. E.g. reads that are cached should also generate atime updates if strictatime, but they don't (regardless of writeback mode). I'd rather fix this properly, i.e. respect relevant mount options: strictatime, noatime, relatime. It shouldn't be complicated, but I haven't looked very deeply. Thanks, Miklos
