C Programming/POSIX Reference/sys/stat.h/stat

stat() is a Unix system call that returns useful data about a file inode. The semantics of stat() vary between operating systems. As an example, the Unix command ls uses it to retrieve information on (among many others):

  • Template:Visible anchor time of last modification (ls -l),
  • Template:Visible anchor time of last status change (ls -lc) and
  • Template:Visible anchor time of last access (ls -lu).

stat() functions and stat structureEdit

The POSIX library header sys/stat.h, found on all POSIX-compliant and Unix-like operating systems, declares the stat(), fstat(), and lstat() routines:

 int stat(const char *filename, struct stat *buf);
 int lstat(const char *filename, struct stat *buf);
 int fstat(int filedesc, struct stat *buf);

and defines the struct stat structure as including at least the following members:

     dev_t       st_dev;     /* ID of device containing file */
     ino_t       st_ino;     /* inode number */
     mode_t      st_mode;    /* protection */
     nlink_t     st_nlink;   /* number of hard links */
     uid_t       st_uid;     /* user ID of owner */
     gid_t       st_gid;     /* group ID of owner */
     dev_t       st_rdev;    /* device ID (if special file) */
     off_t       st_size;    /* total size, in bytes */
     time_t      st_atime;   /* time of last access */
     time_t      st_mtime;   /* time of last modification */
     time_t      st_ctime;   /* time of last status change */
     blksize_t   st_blksize; /* blocksize for filesystem I/O */
     blkcnt_t    st_blocks;  /* number of blocks allocated */

Related functionsEdit

lstat()Edit

lstat() is a library function that retrieves the status of a file. It is identical to stat(), except when the file is a symbolic link, in which case information about the link itself is returned instead of the linked-to file.

fstat()Edit

fstat() is a library function that retrieves the status of a file. It is identical to stat() except that the file's identity is passed as a file descriptor instead of as a filename.

Criticism of atimeEdit

Writing to a file changes its mtime and ctime, while reading a file changes its atime. As a result, on a POSIX-compliant system, reading a file causes a write, which has been criticized. This behaviour can usually be disabled by adding a mount option in /etc/fstab.

However, turning off atime updating breaks POSIX compliance, and some applications, notably the mutt mail reader (in some configurations), and some file usage watching utilities, notably tmpwatch. In the worst case, not updating atime can cause some backup programs to fail to backup a file.

Linux kernel developer Ingo Molnár called atime "perhaps the most stupid Unix design idea of all times,"[1][2] adding: "[T]hink about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'" He further emphasized the performance impact thus:

Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_.

SolutionsEdit

Current versions of Linux, Mac OS X, Solaris, FreeBSD, NetBSD, and OpenBSD support a Template:Visible anchor mount option, which causes the atime field never to be updated. This breaks compliance with POSIX.

Current versions of Linux support four mount options, which can be specified in fstab:

  • strictatime (formerly atime, and formerly the default; strictatime as of 2.6.30) – always update atime.
  • relatime – (relative atime), introduced in 2.6.20 and the default as of 2.6.30
  • nodiratime – do not update atime of directories ever
  • noatime – do not update atime ever; includes nodiratime; highest performance, least compatible

strictatime accords with POSIX; Alan Cox described the alternatives as:

Turn off atime and it is very non standards compliant, turn to relatime and it is not standards compliant but nobody will break (which is good)

File systems mounted with the noatime option do not update the atime on reads, and the relatime option provides for updates only if the previous atime is older than the mtime or ctime, or the previous atime is over 24 hours in the past. Many users use noatime without problem, so long as they do not use an application which depends on atime, and this offers some benefits over relatime (no writing of atime ever on read).

As of 2.6.30 (9 June 2009), Linux defaults to relatime,[3] so that it will not update atime on all file reads. The behavior offers sufficient performance for most purposes and should not break any significant applications. Extended discussion of filesystem performance preceded decision.[4] Indeed, relatime by default was the first patch Linux applied following the 2.6.29 release. In initial patches relatime only updated atime if atime < mtime or atime < ctime; this was subsequently modified to update atimes that were 24 hours old or older, so that tmpwatch and Debian's popularity counter (popcon) would behave properly.

See further discussion at the references.[5][6]

ctimeEdit

Note that ctime has nothing to do with file creation time. It is updated any time file content changes (together with mtime), and also by changes in metadata such as file permissions, file ownership, and creation and deletion of hard links. In some implementations, ctime is affected by renaming a file (both original Unix and modern Linux tend to do this).

Unlike atime and mtime, ctime cannot be set with utime() (as used e.g. by touch); the only way to set it to an arbitrary value is by changing the system clock.

Granularity of mtime etc.Edit

time_t provides times accurate to 1 second.

Some filesystems provide greater granularity. In linux kernels 2.5.48 and above, the stat structure supports nanosecond resolution for the three file timestamp fields. These are exposed as additional fields in the stat structure.

The FAT filesystem provides timestamps with a granularity of 2 seconds.[7]

ReferencesEdit

  1. Kernel Trap: Linux: Replacing atime With relatime, by Jeremy, August 7, 2007
  2. Once upon atime, LWN, by Jonathan Corbet, August 8, 2007
  3. Linux 2 6 30, Linux Kernel Newbies
  4. That massive filesystem thread, LWN, by Jonathan Corbet, March 31, 2009
  5. Installing Linux on USB – Part 4: noatime and relatime mount options
  6. Relatime Recap, Valerie Aurora
  7. How accurate is ruby mtime and friends at StackOverflow.com

External linksEdit

Last modified on 23 November 2013, at 01:12