File Metadata

01 Introduction

Lesson 10.1 presented the file and directory abstractions: a file as a named, persistent sequence of bytes, and a directory as a mapping from names to files. It introduced the idea that a file has attributes — information about the file that is separate from its contents — and it noted that those attributes are stored in the file system's metadata structures, not in the file itself. This lesson examines those attributes in detail.

File metadata is the collection of information that a file system maintains about a file: everything except the file's data. The distinction is fundamental. When a program calls open, the file system reads the metadata to check permissions and to find the file's contents. When a program calls stat, the file system reads the metadata and returns it without touching the contents at all. When a file is modified, the file system updates the metadata (the modification time, the size, the block count) as well as the contents. The metadata is a first-class part of the file, and its correctness and its performance matter as much as the contents'.

The metadata is significant for three reasons. First, it is what makes a file more than a sequence of bytes: the metadata gives a file its identity (its inode number), its name (through the directory), its type, its owner, and its permissions. Second, the metadata is what the file system uses to find the file's contents: the pointers to the file's data blocks are stored in the metadata, not in the data itself. Third, the metadata is what the kernel consults on every access: the permission check, the dirty-flag check, the timestamp update, and the lookup of the file's data blocks all involve reading or writing the metadata.

This lesson presents the metadata in the order that a program encounters it: the standard stat interface (which exposes the metadata to user space), the file's identity (device and inode number, link count), the file's type and permission bits, the ownership fields, the three timestamps and their semantics, the file's size and block count (including the special case of sparse files), and the extended attributes and access control lists that modern file systems provide. It closes with a discussion of where the metadata lives — the inode, which is the subject of Lesson 10.3 — and of the cost of metadata updates, which is the motivation for journaling (Lesson 10.6) and for the design of modern file systems (Lesson 10.7).

02 Learning objectives

This lesson contributes to U10.2 and U10.3, and to course learning outcomes CLO1, CLO5, and CLO6.

03 Required reading

• Operating System Concepts — Chapter 13, Section 13.1, File Concept, and Chapter 14, Section 14.2, File-System Implementation. The standard treatment of file attributes and of the inode as the container of metadata.
• OSTEP — Chapter 39, Files and Directories, and Chapter 40, File System Implementation. OSTEP's treatment of the stat interface and of the inode as the metadata structure is the clearest available account, and it is the basis for the worked example in this lesson.
• Tanenbaum & Bos — Modern Operating Systems, Chapter 4, Sections 4.1 and 4.3, Files and File-System Implementation. The treatment of file attributes and the role of the inode.
• Silberschatz et al. — Chapter 13, Section 13.1, and Chapter 14, Section 14.2. Read the discussion of the attributes and of the inode's fields.
• Kerrisk, M. — The Linux Programming Interface, Chapter 15, File Attributes, and Chapter 16, Extended Attributes. The definitive reference for the stat structure, its fields, and the Linux-specific extensions.
• Bryant, R. E., & O'Hallaron, D. R. — Computer Systems: A Programmer's Perspective, 3rd ed., Chapter 10, System-Level I/O, and Chapter 9, Virtual Memory, section 9.10. The programmer's view of file metadata and of the interaction between the file system and the page cache.
• McKusick, M. K., Joy, W. N., Leffler, S. J., & Fabry, R. S. — A Fast File System for UNIX. ACM Transactions on Computer Systems, 1984. The paper that refined the inode structure and the metadata layout for performance, and that established many of the design principles still in use.
• Linux man pages: man 2 stat, man 2 lstat, man 2 fstat, man 2 statx, man 2 chmod, man 2 chown, man 2 utime, man 2 utimensat, man 2 truncate, man 7 symlink, man 7 xattr, man 5 acl, man 1 stat, man 1 getfattr, man 1 setfattr, man 1 getfacl, man 1 setfacl, man 5 proc (for the /proc/<pid>/stat interface).

04 Core content

4.1 What is file metadata?

File metadata is the collection of information that a file system maintains about a file, excluding the file's contents. It includes the file's identity, its type, its ownership, its permissions, its size, its timestamps, and any other attributes the file system supports. On Unix-like systems, the metadata is stored in the file's inode (Lesson 10.3), and it is exposed to user space through the stat family of system calls.

The metadata is not a separate entity from the file: it is the file, in the sense that the file's identity is its inode number and its contents are located through the pointers in the metadata. When you delete a file, you are removing the directory entry that refers to the metadata's inode; the metadata itself is freed when the last reference to it is gone. When you rename a file, you are changing the directory entry that refers to the inode; the metadata is unaffected. When you modify a file, you are changing the contents, and the metadata is updated to reflect the change (the modification time, the size, and the block count are all adjusted).

The metadata's layout and its relationship with the file's data are central to the file system's design. On classical Unix file systems, the metadata is stored in a fixed-size structure (the inode) whose location is determined by the file's inode number, and the file's data blocks are located through pointers stored in the inode. On modern file systems, the metadata may be stored in a more flexible structure — a B-tree, a log, or a copy-on-write tree — but the principle is the same: the metadata records the file's attributes and provides the pointers to the file's contents.

4.2 The stat interface

The metadata is exposed to user space through the stat family of system calls. The calls fill in a struct stat structure, which is the user-space view of the file's metadata. On Linux, the structure has the following fields:

struct stat {
    dev_t     st_dev;      /* device containing the file */
    ino_t     st_ino;      /* inode number (file identity) */
    mode_t    st_mode;     /* file type and permission bits */
    nlink_t   st_nlink;    /* number of hard links */
    uid_t     st_uid;      /* user ID of the owner */
    gid_t     st_gid;      /* group ID of the group */
    dev_t     st_rdev;     /* device ID (for device files) */
    off_t     st_size;     /* total size in bytes */
    blksize_t st_blksize;  /* preferred block size for I/O */
    blkcnt_t  st_blocks;   /* number of 512-byte blocks allocated */
    struct timespec st_atim;  /* time of last access */
    struct timespec st_mtim;  /* time of last modification */
    struct timespec st_ctim;  /* time of last status change */
    /* Linux also provides st_birthtim (creation time) in statx */
};

The three calls differ in how they interpret the path:

• stat(path, buf) — fills in the structure with the metadata of the file that path refers to, following symbolic links. If path is a symbolic link, the metadata returned is that of the target, not the link.
• lstat(path, buf) — the same, but does not follow symbolic links. If path is a symbolic link, the metadata returned is that of the link itself (its size is the length of the pathname it contains, and its type is symbolic link).
• fstat(fd, buf) — takes an open file descriptor rather than a path, and fills in the structure with the metadata of the file the descriptor refers to. Useful for files that have been opened but whose path is not known, or that may have been renamed since they were opened.

Linux also provides statx, an extended version of stat that exposes additional fields, including the file's creation time (stx_btime), the file's attributes (stx_attributes), and the file's mount ID. The extended interface is the subject of section 4.8.

4.3 File identity

A file's identity is the pair (st_dev, st_ino): the device that contains the file and the inode number within that device. The pair is necessary because an inode number is meaningful only within a single file system; the same inode number can refer to different files on different devices. Together, the pair uniquely identifies the file within the entire system.

Programs that need to determine whether two paths refer to the same file compare their (st_dev, st_ino) pairs. This is what find does to detect hard links to the same file, what rsync does to detect files that have been renamed, and what the kernel's directory-entry cache uses to recognise when two paths resolve to the same file.

The st_nlink field records the link count: the number of hard links to the file. When a hard link is created, the count is incremented; when a hard link is removed, the count is decremented. The file's inode is freed only when the count reaches zero and no process has the file open. The link count is a crucial part of the file system's bookkeeping: it is what allows the file to remain accessible through other names after one of its names is deleted, and what ensures that the file's resources are reclaimed only when the last reference is gone.

On Unix, the link count for a regular file starts at 1 when the file is created (there is one name: the file itself). For a directory, the link count starts at 2 — one for the directory's own name in its parent, and one for the . entry inside it. Each subdirectory adds one more to the count, because each subdirectory contains a .. entry that refers to its parent. This is why a directory's link count is one plus the number of its immediate subdirectories.

4.4 File type and mode bits

The st_mode field encodes two pieces of information: the file's type and its permission bits. The type is stored in the high bits of the field, and the permission bits in the low nine bits. The standard types are:

The permission bits occupy the low nine bits of st_mode and are organised into three triplets: the owner's permissions, the group's permissions, and the permissions for everyone else. Each triplet contains a read bit, a write bit, and an execute bit. The symbolic constants are S_IRUSR, S_IWUSR, S_IXUSR for the owner, S_IRGRP, S_IWGRP, S_IXGRP for the group, and S_IROTH, S_IWOTH, S_IXOTH for others.

The meaning of the execute bit depends on the file's type. For a regular file, the execute bit grants permission to execute the file as a program. For a directory, the execute bit grants permission to search the directory — that is, to look up names within it. A directory with read permission but not execute permission can be listed (the names can be read), but the entries cannot be accessed (the names cannot be resolved to inodes). A directory with execute permission but not read permission can be traversed (a path through it can be resolved) but its contents cannot be listed. The combination is unusual but legal.

Three additional bits are stored in the same field, in positions adjacent to the permission bits:

• Set-user-ID (SUID) — When an executable file with the SUID bit is run, the process runs with the privileges of the file's owner, not the user who invoked it. This is how programs like passwd are able to modify /etc/shadow, which is writable only by root.
• Set-group-ID (SGID) — The same, but for the group. On a directory, the SGID bit has a different meaning: files created in the directory inherit the directory's group, not the creating user's group. This is used for shared project directories.
• Sticky bit — On a directory, the sticky bit restricts deletion: a file in a sticky directory can be deleted only by its owner, the directory's owner, or root. This is used for directories like /tmp, where many users create files but should not be able to delete each other's.

4.5 Ownership and the permission-check algorithm

The st_uid and st_gid fields record the file's owner and group. They are used for the permission check — the kernel compares the calling process's effective user and group IDs against the file's — and for accounting (which user owns how much data).

The permission check is performed on every access, and its algorithm is specific enough to be worth stating precisely. When a process tries to access a file, the kernel applies the following rules, in order:

1. If the process's effective UID is 0 (root), the access is allowed. Root bypasses the permission checks entirely, with two important exceptions: executing a regular file requires at least one execute bit to be set, and writing to a file in a read-only file system is not allowed. The exceptions exist so that root cannot accidentally execute a non-executable file or modify a read-only file system.
2. Otherwise, if the process's effective UID equals the file's st_uid, the owner's permission bits (the high triplet of the nine bits) are used. The group and other bits are ignored, even if they would grant more permission.
3. Otherwise, if the process's effective GID (or one of its supplementary GIDs) equals the file's st_gid, the group's permission bits (the middle triplet) are used.
4. Otherwise, the other permission bits (the low triplet) are used.

The order is significant. The owner check comes before the group check, and the group check comes before the other check. The kernel applies one set of bits, not all three: if the process is the owner, the owner's bits apply even if the other bits would grant more permission. This is why a file with mode ---rwxrwx (no permission for the owner, full permission for everyone else) is inaccessible to the owner, but accessible to every other user.

The check is performed against the process's effective UID and GID, not its real ones. The distinction matters for the set-user-ID and set-group-ID mechanisms: when a process runs a set-user-ID binary, its effective UID is changed to the file owner's UID, and the permission check uses the changed value. This is what allows the program to access files the invoking user could not otherwise access.

4.6 Timestamps

The metadata contains three or four timestamps, each updated under different conditions. Their semantics are subtle, and they are the part of the metadata most often misunderstood.

st_atim — access time (atime)

The time of the file's last read. Updated when a program reads the file's contents, or when a program lists a directory's contents. Not updated when the file's metadata is read (as with stat), except under the strictatime policy. The access time is useful for archival tools (which can identify files that have not been read for a long time) and for intrusion detection (which can identify files that have been read unexpectedly), but it is expensive to maintain, because it must be updated on every read.

st_mtim — modification time (mtime)

The time of the file's last content modification. Updated when a program writes to the file's contents, truncates the file, or creates a new file. Not updated when the file's metadata is changed (changing the permission bits or the owner does not update the mtime). The modification time is the timestamp that most tools use as the file's "version" — it is what make compares to decide whether a target needs to be rebuilt, and what rsync compares to decide whether a file has changed.

st_ctim — status change time (ctime)

The time of the file's last metadata change. Updated when the inode is modified: when the permission bits are changed, when the owner is changed, when the link count is changed, when the file's size changes, when the file is renamed, and when the file's content is modified (because content modification also updates the inode's size and modification time). The ctime is therefore a superset of the mtime: every mtime update also updates the ctime, but the ctime can be updated without the mtime (a permission change updates the ctime alone).

st_birthtim — creation time (birthtime)

The time at which the file was created. Not all file systems support it, and not all kernels expose it: classical Unix file systems did not track the creation time, and the classical struct stat has no field for it. Modern file systems (ext4, XFS, Btrfs, ZFS, APFS, NTFS) do track the creation time, and Linux exposes it through the extended statx interface as stx_btime. The field is sometimes called the birthtime to distinguish it from the ctime.

The three classical timestamps — atime, mtime, and ctime — are the ones that every Unix system provides. The birthtime is a modern addition. The distinctions between them are easy to confuse, and it is worth restating: mtime is the content, ctime is the metadata, atime is the read.

The timestamps are also the subject of a Linux-specific optimisation that is worth understanding. Updating atime on every read is expensive, because it turns every read into a write to the inode. The write is small — a few bytes — but it requires the inode to be located, the disk block to be read, modified, and written back, and it can be a significant fraction of the cost of a read that would otherwise be served entirely from the page cache. To avoid this cost, Linux provides three mount options that control when atime is updated:

• strictatime — Update atime on every read. This is the classical behaviour, and it is what the POSIX standard requires. It is rarely used because of its cost.
• relatime — Update atime only if the file's current atime is older than its mtime or ctime, or if more than a day has passed since the last update. This is the default on most Linux systems. It preserves the timestamps' usefulness for most purposes while eliminating the cost of updating them on every read.
• noatime — Never update atime. This is the fastest option, but it makes atime useless. It is used on systems where performance matters more than the access-time information, and on systems where the atime field is not needed (many modern systems use noatime on their root file systems).

The choice of policy is a trade-off between performance and the usefulness of the atime field. Most modern systems choose relatime as a compromise: it updates the field often enough for archival tools and intrusion detection, but rarely enough to avoid the cost on the common case of a file that is read repeatedly.

4.7 Size and block counts

The metadata records two measures of the file's size: st_size, the logical size in bytes, and st_blocks, the number of 512-byte blocks actually allocated on disk. The two are usually related (the block count is at least the logical size divided by 512), but they can differ in both directions.

The most common reason for a difference is block alignment. A file system allocates space in fixed-size blocks (typically 4 KB on ext4, 8 KB or larger on some others), and the last block of a file may be only partially used. A file with a logical size of 1 byte occupies one full block on disk, so st_size is 1 and st_blocks is 8 (one 4 KB block divided into 512-byte units). The difference is the file system's internal fragmentation, and it is the price of the file system's block granularity.

The other reason is the opposite: a file's st_size can be much larger than the space it actually occupies. This is the case for a sparse file, a file whose logical size includes "holes" — regions that contain no data. A sparse file is created when a program seeks past the end of the file and writes data there, or when a program explicitly creates a sparse file with ftruncate or lseek. The file system does not allocate blocks for the holes: the metadata's block pointers are NULL for the hole's regions, and the file system returns zeros when a program reads them. The result is a file whose st_size may be many gigabytes but whose st_blocks may be only a few megabytes.

Sparse files are useful for several purposes. A virtual machine's disk image is typically sparse: the image's logical size is the size of the virtual disk, but the space actually allocated is only the space the guest operating system has written. A database's file might be sparse: the file is pre-allocated to a maximum size, but the space for unused records is not allocated. A scientific computation's output file might be sparse: the file is large, but only the regions the computation actually produced contain data.

The handling of sparse files is one of the differences between file systems. The classical Unix file system and its descendants (ext2, ext3, ext4) handle sparse files by leaving the block pointers for a hole empty. Modern file systems (XFS, Btrfs, ZFS) handle them more efficiently, using extents — a range of contiguous blocks with a single descriptor — which allows a hole to be represented by a single descriptor rather than by the absence of many pointers. And some file systems support hole punching: an operation that creates a hole in an existing file, freeing the blocks that were allocated there. Hole punching is used in files that have been written and then have regions marked as "do not care", such as the tail of a virtual machine's disk image after a snapshot.

4.8 Extended attributes

The classical struct stat exposes the metadata that the POSIX standard specifies, but modern file systems support additional metadata that does not fit in the classical structure. This additional metadata is stored in extended attributes (xattrs), which are named key-value pairs associated with a file.

An extended attribute has a name and a value. The name is a string in a namespaced format: on Linux, the namespaces are user. (for user-defined attributes), trusted. (for attributes visible only to privileged processes), security. (for security attributes such as SELinux labels and capabilities), and system. (for system attributes such as POSIX ACLs). The value is a byte string whose meaning is determined by the namespace and by the application that uses it.

Extended attributes are used for several purposes.

• Access control lists. On Linux, POSIX ACLs are stored as extended attributes in the system. namespace. The classical permission bits remain in the inode; the ACL extends them with additional entries.
• Security labels. SELinux and AppArmor store their security context in security. attributes.
• File capabilities. The security.capability attribute stores the capabilities that a program should have when it is executed, as an alternative to the set-user-ID mechanism.
• File system features. A file system may use extended attributes for its own bookkeeping: for example, to record the file's checksums, its encryption keys, or its compression flags.
• Application metadata. An application may store arbitrary metadata in the user. namespace: the source URL of a downloaded file, the encoding of a document, the thumbnail of an image.

The support for extended attributes varies between file systems. On Linux, ext4 supports extended attributes up to a limited total size (typically a few kilobytes per inode), and they are stored either inline in the inode or in a separate block pointed to by the inode. XFS, Btrfs, and ZFS support extended attributes with larger limits. The interface for manipulating them is setxattr, getxattr, listxattr, and removexattr, and the command-line tools are setfattr and getfattr.

4.9 Access control lists

The classical Unix permission model is a good fit for the majority of cases: a file has an owner, a group, and a set of permissions, and that is sufficient. But it has a fundamental limitation: it can express permissions for at most one group. A file that needs to be readable by three different groups, or by a specific list of users, cannot be expressed in the classical model without creating additional groups or duplicating the file.

Access control lists (ACLs) extend the model with a list of entries, each specifying a user or group and a set of permissions. The list is consulted after the classical permission bits: if the classical bits already allow the access, the ACL is not consulted; if they do not, the ACL is checked for an entry that grants the access.

A POSIX ACL has up to three kinds of entry:

• User entries — one for the file's owner (the user:: entry, which corresponds to the classical owner bits) and zero or more for specific users (the user:alice: entries).
• Group entries — one for the file's owning group (the group:: entry, which corresponds to the classical group bits) and zero or more for specific groups (the group:staff: entries).
• Other entries — one for everyone else (the other:: entry, which corresponds to the classical other bits).
• Mask entry — a special entry that limits the permissions granted by the user and group entries. The mask is intersected with the permissions in each entry, so the effective permission of a user entry is the entry's permission AND the mask.

The ACL's entries are stored in an extended attribute (system.posix_acl_access), and the classical permission bits continue to exist alongside them. The classical bits and the ACL are kept in sync: changing the classical bits with chmod updates the ACL's owner, group, and other entries, and changing those entries in the ACL updates the classical bits. This is why chmod works on a file with an ACL, and why the interaction between the two is more subtle than it first appears.

ACLs are a powerful tool, but they are also a source of complexity. A file with an ACL behaves differently from a file without one: the permission check requires reading the ACL, the ls -l output shows a + after the mode to indicate the presence of an ACL, and the classical permission bits have a different meaning (they are the maximum, not the actual permissions). Most systems therefore use ACLs sparingly, for the cases where the classical model is genuinely insufficient.

4.10 Where metadata lives

The metadata is stored in the file system's own structures, separate from the file's data. On classical Unix file systems, this structure is the inode, a fixed-size record whose location is determined by the file's inode number. The inode contains all the file's metadata — its type, its permissions, its owner, its size, its timestamps, and the pointers to its data blocks — and it is read and written as a unit.

Modern file systems have relaxed the fixed-size, fixed-location assumption of the classical inode. Ext4 still uses fixed-size inodes but supports extended attributes that spill into additional blocks. XFS uses variable-size inodes that can grow as needed. Btrfs and ZFS store metadata in B-trees and copy-on-write trees, with no separate inode structure at all: the file's metadata is a node in a tree, and the tree is updated atomically. The struct stat interface is preserved across these changes — the metadata is still exposed to user space in the same way — but the internal representation is different.

The separation of metadata from data has a cost. Reading a file requires the file system to read the file's metadata (to find the data blocks) and then read the data blocks themselves. For a small file, the metadata read dominates; for a large file, the data reads dominate. And writing a file requires updating both the data blocks and the metadata (the size, the modification time, the block pointers), so a single write can involve several disk accesses to different parts of the file system. This is the subject of Lesson 10.5 (file allocation) and Lesson 10.6 (journaling), which examine the strategies for laying out the metadata and for keeping it consistent in the face of crashes.

4.11 Common misconceptions

05 Worked example

The following example interprets the metadata of several files, traces the permission-check algorithm through a specific case, and demonstrates the behaviour of sparse files.

st_dev    = 0x0801            /* device 8, minor 1 */
st_ino    = 262147
st_mode   = 0x81A4            /* 0100644 in octal */
st_nlink  = 3
st_uid    = 1000              /* alice */
st_gid    = 100              /* staff */
st_rdev   = 0
st_size   = 40960             /* 40 KB */
st_blksize = 4096
st_blocks = 80                /* 80 × 512 = 40 KB */
st_atim   = 1712345678.123456789
st_mtim   = 1712345000.987654321
st_ctim   = 1712345000.987654321

#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>

int main(void) {
    int fd = open("sparse.bin", O_WRONLY | O_CREAT | O_TRUNC, 0644);
    if (fd < 0) { perror("open"); return 1; }

    /* write one byte at offset 0 */
    if (write(fd, "A", 1) != 1) { perror("write"); return 1; }

    /* seek to 1 GB past the start */
    if (lseek(fd, 1024L * 1024 * 1024, SEEK_SET) == -1) {
        perror("lseek"); return 1;
    }

    /* write one byte at the new position */
    if (write(fd, "B", 1) != 1) { perror("write"); return 1; }

    close(fd);
    return 0;
}

$ stat sparse.bin
  File: sparse.bin
  Size: 1073741825  Blocks: 8  IO Block: 4096  regular file
Device: 801h/2049d    Inode: 524291      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   alice)   Gid: ( 100/  staff)
Access: 2025-04-05 10:15:32.123456789 +0000
Modify: 2025-04-05 10:15:32.123456789 +0000
Change: 2025-04-05 10:15:32.123456789 +0000
 Birth: 2025-04-05 10:15:32.123456789 +0000

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• File metadata is the information a file system maintains about a file, excluding its contents. It includes the file's identity, type, ownership, permissions, size, timestamps, and other attributes.
• The metadata is exposed to user space through the stat family of system calls, which fill in a struct stat structure. The three calls — stat, lstat, and fstat — differ in how they interpret the argument: stat follows symbolic links, lstat does not, and fstat operates on an open file descriptor.
• A file's identity is the pair (st_dev, st_ino): the device and the inode number within that device. The pair is used to uniquely identify a file, because inode numbers are meaningful only within a single file system.
• The link count (st_nlink) is the number of hard links to the file. The inode is freed only when the link count reaches zero and no process has the file open.
• The mode bits (st_mode) encode the file's type and its permission bits. The types are regular file, directory, symbolic link, character device, block device, FIFO, and socket. The permission bits are the owner, group, and other triplets, plus the set-user-ID, set-group-ID, and sticky bits.
• The permission-check algorithm checks the effective UID and GID against the file's owner and group. Root bypasses the checks (with two exceptions). Otherwise, the first matching category — owner, group, or other — determines the permissions used; the kernel applies exactly one set of bits, not all three.
• The three timestamps record different events: atime is the time of the last read, mtime is the time of the last content modification, and ctime is the time of the last metadata change (including content changes). The birthtime (creation time) is available on modern file systems through statx.
• Linux supports three policies for updating atime: strictatime (every read), relatime (the default; only when the current atime is older than mtime or ctime, or after a day), and noatime (never). The choice balances performance and the usefulness of the field.
• A file's logical size (st_size) is the number of bytes in the file; its allocated size (st_blocks × 512) is the space it occupies on disk. The two can differ because of block alignment or because the file is sparse — a file with holes, whose logical size includes regions that contain no data and are not allocated on disk.
• Extended attributes (xattrs) are named key-value pairs associated with a file, in namespaces such as user., trusted., security., and system.. They are used for ACLs, security labels, file capabilities, file-system bookkeeping, and application metadata.
• Access control lists (ACLs) extend the classical permission model with entries for specific users and groups. They are stored in the system.posix_acl_access extended attribute, and they interact with the classical permission bits in ways that are worth understanding.
• The metadata lives in the file's inode (or its equivalent in modern file systems). The inode's structure and lifetime are the subject of Lesson 10.3; the strategies for laying out the metadata and for keeping it consistent in the face of crashes are the subject of Lessons 10.5 and 10.6.

11 References

• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 13, Section 13.1, and Chapter 14, Section 14.2.
• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, Chapters 39 and 40. Available online at ostep.org.
• Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 4, Sections 4.1 and 4.3.
• Kerrisk, M. The Linux Programming Interface. No Starch Press, 2010. Chapters 15 and 16. The definitive reference for the stat structure, its fields, and Linux's extended attributes.
• Bryant, R. E., & O'Hallaron, D. R. Computer Systems: A Programmer's Perspective, 3rd ed., Chapter 10, System-Level I/O.
• McKusick, M. K., Joy, W. N., Leffler, S. J., & Fabry, R. S. A Fast File System for UNIX. ACM Transactions on Computer Systems, 1984. The paper that refined the inode structure and the metadata layout.
• Ritchie, D. M., & Thompson, K. The UNIX Time-Sharing System. Communications of the ACM, 1974. The original paper that established the Unix file and metadata model.
• IEEE Std 1003.1-2017 (POSIX.1-2017). The specification of the struct stat fields and the stat family of system calls.
• Linux man-pages: man 2 stat, man 2 lstat, man 2 fstat, man 2 statx, man 2 chmod, man 2 chown, man 2 utime, man 2 utimensat, man 2 truncate, man 7 xattr, man 5 acl, man 5 proc, man 1 stat, man 1 getfattr, man 1 setfattr, man 1 getfacl, man 1 setfacl.