Skip to main content

Module fs_kind

Module fs_kind 

Source
Expand description

Which filesystem holds a path (btrfs, overlayfs, other) and whether a directory is a btrfs subvolume root. What: Which kind of filesystem holds a path (btrfs, overlayfs, other), whether a directory is the root of a btrfs subvolume, and how many bytes a user can still write there. Why: Every rung of the cheap-worktree ladder starts from these three facts, which the kernel answers in one statfs call and one inode number, so nothing is spawned: a snapshot needs btrfs and a subvolume root (inode 256), a reflink works on btrfs and inside an overlay, and everything else keeps Git’s own checkout. doc/planning/cli-git-btrfs-worktree.md (section “Degradation ladder”) has the measurements behind the ladder.

In TS you’d write (pseudocode):

const kind = (await statfs(path)).type === 0x9123683e ? 'btrfs' : ...;
const isSubvolumeRoot = kind === 'btrfs' && (await stat(path, { bigint: true })).ino === 256n;

Enums§

FilesystemKind
What: The filesystem kinds the ladder tells apart. #[derive(...)] generates copying, debug printing and ==. Why: Btrfs allows snapshots and reflinks, overlayfs allows reflinks of files inside it, anything else gets Git’s checkout.

Constants§

BTRFS_SUBVOLUME_ROOT_INODE
The inode number of the root directory of every btrfs subvolume (BTRFS_FIRST_FREE_OBJECTID, include/uapi/linux/btrfs_tree.h).

Functions§

classify_magic
What: Map the f_type of a statfs answer to a kind. u64 is the widest unsigned integer; siblings u32 and i64 are what the C field is on some targets. Why: The C field is a signed word on some targets and an unsigned one on others, so only its low 32 bits are compared with the magic numbers, which are all 32-bit values.
filesystem_facts
What: The kind of filesystem that holds path, and the bytes a user can write there, from one statfs call. Why: The two answers come from the same call, so a caller that wants both pays once.
filesystem_kind
What: The kind of filesystem that holds path. Why: Most callers need only the kind.
is_subvolume_root
What: Whether path is the root directory of a btrfs subvolume. Why: Only a subvolume root can be the source of a snapshot. Inode 256 is the root of every subvolume; on another filesystem the same inode number means nothing, so the filesystem is checked first and a directory on a filesystem other than btrfs is never a subvolume root.
is_xfs
What: Whether path is on an XFS filesystem. Why: XFS shares data blocks between files when it was made with reflink support, which the first clone reveals, so the clone rung of the cheap-worktree ladder is tried there although the ladder’s FilesystemKind has no XFS.