Btrfs

What is it?

Btrfs is the default filesystem on Fedora Workstation and openSUSE and the recommended one on Synology network storage, so it is what a user often finds when they pull a disk out of a Synology NAS or a Linux desktop. A Synology volume sits on Linux software RAID (and usually LVM) underneath Btrfs, which the roadmap does not cover, so such a disk is not directly readable even once the driver exists. Impossible OS has no Btrfs code and does not recognise a Btrfs partition. This roadmap adds a read-only driver in ten sections, none of them started. Writing is deliberately out of scope: the copy-on-write B-tree write path is one of the largest and most delicate parts of the Linux implementation, and reading covers the recovery and data-access case.

How does it work?

Today. probe_filesystem() in partition.c checks each partition for IXFS, NTFS, FAT32 and ext2. There is no Btrfs check, so a Btrfs partition is classed PART_FS_UNKNOWN (partition.h) and skipped. The one piece the driver can reuse already exists: kcrc32c() in kchecksum.h. CRC32C is Btrfs's default checksum; a volume created with xxhash, SHA-256 or BLAKE2b checksums will need its checksum type read from the superblock and, until those are supported, refused rather than reported as corrupt.

Planned design. Btrfs stores everything in B-trees that address data by logical address, so the order of work is fixed:

Read the superblock at 64 KiB, check its checksum type, and verify its CRC32C, falling back to the backup copies.
Parse B-tree nodes and leaves, checking each node's checksum.
Build the chunk map that turns logical addresses into physical ones. It bootstraps from the small chunk array inside the superblock, then reads the full chunk tree; single-device and RAID1 layouts are in scope, and a RAID5 or RAID6 volume is refused.
A generic tree search and walk.
The root tree, to list subvolumes, which appear under a virtual .btrfs directory.
Inodes, file extents (plain, inline, preallocated and compressed with zlib, LZO or Zstd), directories, symbolic links and extended attributes.
VFS registration with every write operation refused.

flowchart LR
    SB[superblock + CRC32C] --> CH[chunk map: logical to physical]
    CH --> TS[tree search]
    TS --> RT[root tree: subvolumes]
    RT --> FS[fs tree: inodes, dirs, extents]
    FS --> DEC[zlib / LZO decompress]
    FS --> V[read-only VFS mount]

What are its interfaces?

None yet. The driver will register a read-only struct vfs_fs_driver with vfs_mount() (vfs.h) and add a btrfs_probe() to the planned probe chain (Volume Management). Programs will read Btrfs files through the ordinary file calls; writes will fail.

How do I use it?

It cannot be used yet. A Btrfs disk attached to the machine is detected as a disk, but its partition gets no drive letter.

What is not implemented yet?

Everything in the roadmap:

The foundation: Superblock Parse + CRC32C Verify, B-Tree Node Format, Chunk Tree and Tree Search + Walk.
Reading files: Root Tree + Subvolume Enumeration, Inode Reader, Extent Data Decoder, Directory Reader and Symlinks + XAttrs.
Mounting: VFS Registration + Probe + Read-Only Mount. The VFS has no read-only mount flag yet, so this section also has to add one.
Writing and RAID5/6 volumes are not planned.

How does it compare with Windows 11 and Linux?

Windows 11 has no Btrfs support; the third-party WinBtrfs driver fills the gap. Linux has read-write Btrfs in the kernel with every compression codec and RAID level, and btrfs-progs for maintenance. Impossible OS plans a native read-only driver, which is enough to copy data off a Linux disk formatted directly with Btrfs.