Btrfs System Rollbacks In Fedora 13

[phoronix]

Phoronix: Btrfs System Rollbacks In Fedora 13

One of the benefits of Btrfs besides offering competitive performance against other Linux file-systems and SSD optimizations is its support for sub-volumes and writable snapshots. While Btrfs is still in development and is not yet used as a default file-system by any Linux distribution, Red Hat has been looking to capitalize upon the capabilities of Btrfs by introducing support for system rollbacks into Fedora. The Btrfs-based system rollback support has been a feature for Fedora 13 so with the release of the Fedora 13 Beta earlier this week we decided to further investigate this feature.

http://www.phoronix.com/vr.php?view=14793

[squirrl]

Great to see them embracing it.

[stan]

Do these snapshots store the entire filesystem or only a diff to what has changed since the previous snapshot? A diff would be better because it would save space. I think that's what Apple's Time machine does.

By the way, how far is Redhat from making a competitor to Apple's Time Machine with this BRFS rollback?

[movieman]

Do these snapshots store the entire filesystem or only a diff to what has changed since the previous snapshot?

I believe btrs snapshots are essentially the same as ZFS, so when you write to a file which exists in a snapshot the old data block is left in the snapshot and not freed. Hence if you have a snapshot with 20GB file and later update a 4k block in that file, then only that 4k block has to be stored in the live copy of the filesystem... for the rest of that 20GB file it will read the same blocks that exist in the snapshot.

[stan]

I believe btrs snapshots are essentially the same as ZFS, so when you write to a file which exists in a snapshot the old data block is left in the snapshot and not freed. Hence if you have a snapshot with 20GB file and later update a 4k block in that file, then only that 4k block has to be stored in the live copy of the filesystem... for the rest of that 20GB file it will read the same blocks that exist in the snapshot.

Aha, so if the user changes 4k since the previous snapshot, the next snapshot will require only 4k of additional space on a backup drive. Sounds good! Thanks for the explanation.

[curaga]

Or if a cosmic particle changes some bits in the main part, all rollbacks are screwed.

[movieman]

Or if a cosmic particle changes some bits in the main part, all rollbacks are screwed.

If you want data integrity with localised bit errors, then you can set up a RAID mirror. I believe btrfs checksums data blocks, so it should be able to determine which one is wrong.

[yesterday]

Do these snapshots store the entire filesystem or only a diff to what has changed since the previous snapshot? A diff would be better because it would save space. I think that's what Apple's Time machine does.

By the way, how far is Redhat from making a competitor to Apple's Time Machine with this BRFS rollback?

It's called copy-on-write

[nanonyme]

Also unless otherwise defined Btrfs snapshots are very similar to normal Btrfs subvolumes and can be written on.

[MattH]

I'm gonna miss ZFS when Oracle screws Sun up, but assuming btrfs is COW and does checksums for each block (and has nifty stuff like integrated compression, share(nfs|smb|iscsi), et al.) I guess I'll survive..

ps: does btrfs have integrated dedup? OpenSolaris ZFS has it IIRC.. At least for the time being..