Filesystem

Extended attributes attach named byte values to filesystem objects outside the ordinary file-content stream. Applications can use the user namespace for small metadata, while other namespaces have kernel, security-module, or privileged semantics. Their usefulness depends on the filesystem, access rules, and transfer tools. A metadata tag is reliable only when the workflow preserves and interprets it according to an explicit contract. ...

A btrfs snapshot is not a copy of anything. btrfs subvolume snapshot creates a new subvolume whose root points at the same extent tree as the source, so every extent the two share is referenced twice and stored once. Creation is a metadata operation measured in milliseconds whether the subvolume holds a gigabyte or ten terabytes. ...

Inotify delivers Linux filesystem notifications through an instance with registered watches and a readable event queue. Each record identifies a watch, event mask, and possibly a name and move cookie. This can avoid repeatedly checking unchanged paths, but the stream is not an unlimited audit log. Correct consumers interpret notifications as evidence that relevant state may need to be inspected again. ...

A sparse regular file can have a large logical length while allocating storage for only part of its address range. Reads from holes within that length return zero bytes. File length, byte content, and filesystem allocation are therefore different measurements. Understanding their relationship matters when budgeting virtual disks, copying backups, or deciding whether a zero-filled region actually reserves space for future writes. ...

A hard link adds another directory entry referring to an existing file. Neither name is intrinsically the original: both identify the same inode within its filesystem. File content, ownership, permissions, and link count belong to that shared object. A filename is a way to reach it, so changes to directory entries must be distinguished from changes to the file itself. ...

A symbolic link is a filesystem object containing a target pathname. Following the link resolves that pathname at the time of the operation; it does not bind the link permanently to the target’s inode. This distinction explains why links can cross filesystem boundaries, become dangling, or start reaching a different object even though their stored target text has not changed. ...

An NFS export is a directory on the server plus a list of clients allowed to reach it; the file that describes it is not what serves it. /etc/exports is read by exportfs, which writes the master export table to /var/lib/nfs/etab, which rpc.mountd consults on a client’s MOUNT request. Three files: one that people edit, two that decide what happens. ...

A read-only root filesystem prevents ordinary writes to the filesystem layer containing a service’s packaged code and configuration. Explicit mounts can still provide writable locations for runtime data. This reduces accidental modification and some persistence opportunities, but its boundary is filesystem mutation. It does not by itself remove process privileges, prevent reading available data, or block communication with other services. ...