Advanced Features of File Systems and Storage

Checksumming, snapshots and support for new storage technologies had all landed in Linux local file systems by 2014. What each of them does, and what each of them costs.

Everybody was waiting on btrfs. XFS and ext4 quietly shipped much of what it was supposed to bring.

Both had grown metadata checksumming by then: ext4’s metadata_csum in 3.5, XFS self-describing metadata and CRC32c in 3.10, and neither turned on by default yet. Btrfs went further and checksummed data as well. But detecting corruption is not the same as being able to do anything about it. Without a second copy to fall back on, a failing checksum tells you the block is wrong and stops there. Better than returning it silently. Still not a repair.

Snapshots split along the same line. Either at the block layer, underneath the file system, where the thing doing the copying has no idea what is in the extents it copies, or at file level, where copy-on-write means the machinery is already there. Thin provisioning under either one moves ENOSPC to write time and into a layer the file system cannot see, which is a considerably worse place to find it.

I spent the last part of the talk on what a file system could tell the storage rather than on what it could work out by itself. Persistent memory is the case where the block layer stops making sense at all: byte-addressable, roughly memory speed, and no reason to batch and reorder anything on the way to it. Hybrid drives are the opposite case, an ordinary rotational disk with a small flash cache, which works well right up until it guesses wrong about which blocks are hot. Nothing in the stack could tell it. That is what user-guided allocation is for, and in early 2014 it was still a good idea rather than an interface.