VFS interface omission? -- doesn't expose fstat

Michael Callahan (mjc@emmy.smith.edu)
Wed, 4 Sep 1996 06:32:56 -0400 (EDT)

Consider a program that opens a file, sleeps for a long time, and then
does fstat on the file descriptor. In the current Linux VFS setup, it
appears that the filesystem layer is totally out of the loop: the
information is copied from the in-memory inode into the user's stat buffer
and that's it. Although this information should be correct for a
disk-based filesystem, in a distributed filesystem the inode attributes
may of course change in a way unknown to the local kernel.

In contrast, the *BSD* (etc) VFS has a GETATTR operation that allows the
filesystem to intervene at this point. In fact, this observation came up
in thinking about how some code written to that interface would work in

As far as I can tell, fstat is the only case where the kernel might use an
inode without giving the filesystem layer some chance to update the inode
information. Note that stat, for example, is not afflicted by the same
problem: it does a lookup VFS operation to find the inode of interest.
The lookup operation can revalidate the looked-up inode before returning
it. (This is what Linux NFS does, for example.)