Linux Kernel 5.3
Consider the fstat
syscall defined as int fstat(int fd, struct stat *statbuf);
. Is disk access required for the fstat
syscall on ext4?
I did some research related to it and find out some info. The in-kernel entry point to the system call is the function vfs_statx_fd
. Here is how its implementation looks like:
int vfs_statx_fd(unsigned int fd, struct kstat *stat,
u32 request_mask, unsigned int query_flags)
{
struct fd f;
int error = -EBADF;
if (query_flags & ~KSTAT_QUERY_FLAGS)
return -EINVAL;
f = fdget_raw(fd);
if (f.file) {
error = vfs_getattr(&f.file->f_path, stat,
request_mask, query_flags);
fdput(f);
}
return error;
}
So what we have here is that the unsigned int fd
which is actual file descriptor that a user passed to the system call is used to find a pointer to the struct file
. The crucial part of its definition is
struct file {
//...
struct path f_path;
struct inode *f_inode; /* cached value */
//...
}
So we basically have that struct file
represents an opened file and the struct contains references to dentry
and inode
Is it true that in case we have an opened file descriptor we can get all the stats just from memory avoiding costly disk access?
Update: I tried to flush Kernel caches with free && sync && echo 3 > /proc/sys/vm/drop_caches && free
right before invoking the syscall
and it did not affect the timing of stat syscall. So I tend to think that no disk access is required.
Best Answer
On an Ext4 file system, the function graph starting from
vfs_statx_fd
isLooking at the implementations of all these functions shows that there’s no provision for disk I/O. As you surmise, the data comes from the cached inode.
See also the
fstat(2)
manpage which mentions that:(although this has more to do with locking than caching).
With some other file systems,
AT_STATX_FORCE_SYNC
can be included in the query flags to force a remote sync; this is supported on Ceph, FUSE, NFS, and VirtualBox guest shared folders.