IXFS Advanced Storage

What is it?

This roadmap adds the features meant to put IXFS ahead of NTFS: sparse files, TRIM, transparent compression, deduplication, reflink copies, online defragmentation and resize, self-healing metadata, scheduled snapshots, per-file encryption, a change journal, quotas, storage tiering and a health dashboard. None of its sixteen sections is complete. What IXFS has today for reliability is a small write-ahead journal, copy-on-write snapshots, a checksum scrub and a repair pass, all built into the version 2 format described in IXFS Core.

How does it work?

Journal. ixfs_journal.c keeps a 16-block (64 KiB) circular journal. A transaction holds at most eight blocks; ixfs_txn_commit() writes a commit record, copies each block to its final place and marks the journal empty, and ixfs_journal_recover() replays what is left at mount. Only block-bitmap and superblock updates go through it. Each entry stores 4080 bytes of its 4096-byte block and checks them with an additive byte sum, and recovery does not check for a commit record before replaying; the defect is filed under Subsystem Verification.

Snapshots. ixfs_cow.c keeps a per-block reference count and up to eight named snapshots (IXFS_MAX_SNAPSHOTS in ixfs.h). A snapshot copies the inode table and raises the reference count of every block in use, so later writes copy the block instead of overwriting it. Snapshots are not safe to rely on yet: ixfs_snapshot_create() allocates one block but writes the whole inode table (several blocks) from that block onward, which can overwrite live data, and ixfs_snapshot_restore() ignores read and write failures and still logs success. Both are open items in Inode-Table + On-Disk-Layout Hardening.

Checksums and scrub. The checksum table holds a CRC32C per block, but only data blocks are covered: ixfs_checksum_verify() in ixfs_core.c skips every block before the data region (superblock, bitmap, checksum table, inode table, journal, refcount and snapshot tables) and any block whose entry is zero. A mismatch on read logs a warning and the data is returned anyway. ixfs_scrub() in ixfs_format.c walks the allocated data blocks with the same exclusions and reports mismatches; it does not repair them.

Repair pass. ixfs_fsck() in ixfs_fsck.c checks the superblock, directory entries, orphaned and cross-linked blocks, the bitmap against the inode table, and journal entries, in check-only or repair mode, and downgrades to check-only on a read-only volume.

Sparse files, in part. An extent starting at block 0 reads as a hole (ixfs_extent.c), and a write past the end of a file leaves a gap rather than zero-filling it. There is no hole punching and no sparse-file attribute.

Nothing in the shell or the desktop calls the scrub, the repair pass or the snapshot functions yet; they run from kernel tests.

flowchart LR
    W[bitmap or superblock write] --> T[ixfs_txn_write]
    T --> C[ixfs_txn_commit: commit record, copy to final block]
    M[mount] --> R[ixfs_journal_recover]
    S[snapshot] --> RC[refcount + inode table copy]
    RC --> CoW[later writes copy the block]
    SC[ixfs_scrub] --> CK[CRC32C table]

What are its interfaces?

Interface	Purpose
`ixfs_txn_begin()`, `ixfs_txn_write()`, `ixfs_txn_commit()`, `ixfs_journal_recover()`	Journal (`ixfs_journal.c`)
`ixfs_snapshot_create()`, `_list()`, `_restore()`, `_delete()`	Snapshots (`ixfs.h`)
`ixfs_scrub()`, `ixfs_fsck()`, `struct ixfs_fsck_report`	Integrity scan and repair
`ixfs_stat()`	Logical size and blocks actually used, for sparse files

How do I use it?

There is no user command yet, and nothing calls the full repair pass: make test-fs runs the suites in test_ixfs_fsck.c, which test its checking helpers (superblock checks, bitmap reconciliation on small in-memory arrays, journal-entry validation) one at a time, not ixfs_fsck() on a damaged volume. When the repair pass does run, the serial log brackets it:

IXFS fsck starting (read-only mode)
IXFS fsck done: <n> errors (orphans=<a> bad-dirents=<b> cross=<c> bitmap=<d> journal=<e>) -- clean

What is not implemented yet?

Storage efficiency: sparse files, TRIM, compression, deduplication and reflink copies.
Maintenance while mounted: defragmentation, resize and self-healing metadata.
Protection and accounting: scheduled snapshots, per-file encryption, a change journal, quotas and tiering.
Visibility and tests: a health dashboard and a test suite.
Mount-time validation of the inode table and layout, plus the ignored write results in unlink and snapshot restore (Inode-Table + On-Disk-Layout Hardening).

How does it compare with Windows 11 and Linux?

NTFS on Windows 11 has sparse files, compression, EFS encryption, the USN change journal, quotas and Volume Shadow Copy snapshots; ReFS adds block cloning and integrity streams. Btrfs on Linux has compression, reflinks, snapshots, scrub and online resize, and ZFS adds deduplication. IXFS has data-block checksums, snapshots and a repair pass today, and none of the efficiency, encryption or accounting features yet.