As you might guessed by now, I played with file-systems for backup appliance So, against my good judgment, I decided to try btrfs to see how ready is it to replace zfs-fuse configuration with real in-kernel file-system (zfs-fuse is not slow, because disks are much slower than any peace of software).
So far, I found following annoyances in brtrs:
- snapshots can't be removed (I'm doing incremental forever backups, so this is not show-stopper)
You can remove all files in snapshot directory, but not directory itself. I would guess that removing files would just increase disk space, because it's copy-on-write filesystem, but I didn't test that. - there is no indication which directory is snapshot (if you didn't wrote down in log which is snapshot, you are out of luck)
- it seeks quite a lot (there is 40-70% wait time in vmstat while running rsync which I guess is seek, because there is no block input/output operations at same time)
- it will oops your (Debian 2.6.29-2-686) kernel:
Message from syslogd@klin at May 16 00:42:31 ... kernel:[ 4057.994566] [<c0119e0f>] kmap_atomic_prot+0xbd/0xdd Message from syslogd@klin at May 16 00:42:31 ... kernel:[ 4057.994576] [<c0119d30>] kunmap_atomic+0x58/0x7a Message from syslogd@klin at May 16 00:42:31 ... kernel:[ 4057.994586] [<f83a61a2>] btrfs_cow_block+0x134/0x13d [btrfs] Message from syslogd@klin at May 16 00:42:31 ... kernel:[ 4057.994608] [<f83a8b4b>] btrfs_search_slot+0x1f0/0x622 [btrfs] Messag./pull-snapshot-backup.sh: line 8: 4316 Segmentation fault rsync -ravHC --numeric-ids --delete $from:/mnt/vz-backup/private/$1/ /$pool/$1/
dmesg-btrfs-bug.txt
After that I concluded that warning about alpha state of btrfs is there with a reason. I didn't fully appreciate Theodore Ts's warning about development status of btrfs until I got kernel oops.