MeeGo and Btrfs

(Btw, #btrfs can be very quiet at times and quite active at other times. Many times people join the channel and ask a question but leave before someone who can answer has seen it. Stick around in-channel for at least 12 hours, there are people in many different time zones.)

Btrfs sections areas of block storage like spinning disks, SSDs, etc. into chunks. You can think of them like block groups in ffs and ext*, but with more capabilities. There are meta-data chunks and data chunks among other types of chunks. The size of the chunks are fixed size once allocated until a rebalance (it can be run while the volume is online, no need to unmount) operation is invoked. I suspect your meta-data chunk was 256MB.

The size of btrfs meta-data can be a bit misleading. Btrfs does tail-packing on the end of files, and if the file is small enough it will be stored entirely in the meta-data chunk.

The numbers reported to df have been a bit misleading until recently. It used to be that used only counted data blocks and free counted all types of free space including free space in the meta-data chunks which couldn't be used for full sized data blocks (only small files and tails). Now used is counted as <used data blocks> + <used meta-data blocks> and free is counted as <free data blocks> + <block space not allocated to any chunk>. This cleared up most of the ambiguity where df was reporting free space, but apps would see disk full errors. (I'm not sure if that made it into 2.6.33.) Though if df reports zero free you can still write small files that fit into tails because that goes into the meta-data chunk.

A patch to mkfs.btrfs and the kernel module that scales the size of meta-data chunks based on blockdev size would be a welcome contribution from the meego developers I suspect.

The Fedora 13 kernel has a more recent version of btrfs than stock 2.6.33 has and the current advice is to run the latest btrfs from git so that duplicate bug reports aren't reported for issues already fixed.

You can find more details of your btrfs volume with these commands:

btrfs-show
(or "btrfs fi sh" in latest git btrfs-progs)

btrfs fi df <path to btrfs volume>
(in latest git btrfs-progs and recent btrfs kernel module)
"fi" is short for "filesystem" and can be shortened as long as it is unambiguous.

In short, it looks like meego will only be using the features that work well in btrfs right now and I suspect with their somewhat narrow use cases it has a good chance of working well for them right now. On that note the btrfs project can always use more patches, testing and documentation.

(I have been testing btrfs for the last few months and I run as my root filesystem on my desktop and laptop. I do not represent the project and only explain what I think I understand of the project and filesystem. Please let me know if you have found any errors.)