Btrfs for Rawhide users?

Posted Nov 19, 2009 6:18 UTC (Thu) by jimparis (guest, #38647)
Parent article: Btrfs for Rawhide users?

Perhaps the biggest problem is that Btrfs snapshots cover the entire filesystem

Another problem is that Btrfs snapshots only cover the entire filesystem. Unless you're in the habit of dropping to single-user mode to do your upgrades and subsequent recoveries, applications will left in a highly inconsistent state when their disk storage suddenly changes from under them.

Makes me wonder if integrating something like checkpoint/restart would be required to make system-wide snapshotting complete. Or "virsh save" + btrfs snapshots, etc.

Btrfs for Rawhide users?

Posted Nov 19, 2009 11:08 UTC (Thu) by farnz (subscriber, #17727) [Link]

I may be misunderstanding the btrfs filesystem format, but it looks to me like a future development of btrfs would allow you to keep snapshots of subtrees, and to assemble views of the filesystem from a mixture of snapshots. I certainly can't see how the B-trees prohibit this.

Of course, there's admin complexity galore here - but I can envisage something that goes "snapshot the filesystem. Replace all of /var except /var/rpm with the live state, leaving /var/rpm as part of this snapshot, replace /home with the live state" as part of a future btrfs version. Then, once the upgrade of the snapshot is complete, you can do "swap snapshot with live state", and get the atomic update you wanted.

Btrfs for Rawhide users?

Posted Nov 19, 2009 11:31 UTC (Thu) by NRArnot (subscriber, #3033) [Link]

Isn't the best answer (until BTRFS is stable) to partition your disk, and use an experimental btrfs partition for storing backups? Snapshot, then rsync for backup only of the changed data to the btrfs filesystem.

Even better using two disks, of course. Click-click scritch ...

Btrfs for Rawhide users?

Posted Nov 19, 2009 13:07 UTC (Thu) by epa (subscriber, #39769) [Link]

Fedora does drop to single-user mode to perform a distribution upgrade. Individual package updates during the life of one release happen asynchronously, but I would hope those can be rolled back using the normal rpm and yum mechanisms (although admittedly there isn't much good user interface for that, as there is for upgrades).

Btrfs for Rawhide users?

Posted Nov 19, 2009 13:55 UTC (Thu) by masoncl (subscriber, #47138) [Link] (2 responses)

Btrfs supports snapshotting on a per-subvolume basis, and subvolumes are a lot like a directory (except you can snapshot them).

So it isn't entirely true that you have to roll back the entire filesystem, but you would have to roll back the entire thing that you've snapshotted.

Exactly what to snapshot is a similar problem to breaking up the FS tree into partitions. Do we keep / and /home separate? If the upgrade fails do we want to roll back just one of the two?

It's a fun problem...to answer another question I see farther down, can we easily recover the space from old snapshots deleted, yes.

Btrfs for Rawhide users?

Posted Nov 23, 2009 22:08 UTC (Mon) by oak (guest, #2786) [Link] (1 responses)

> It's a fun problem...to answer another question I see farther down, can
we easily recover the space from old snapshots deleted, yes.

And if running processes are still keeping files open from the old state
of the file system (like previous version of the C-library kept open by
every process mmap), what do you do?

Kill all those process when deleting the old snapshot? Tell that snapshot
is busy and cannot be deleted and just list processes or recommend reboot
to get rid of them?

a file which a process holds open is still an inode in the mounted fs, even if no filename points to it.

Posted Nov 27, 2009 3:29 UTC (Fri) by xoddam (subscriber, #2322) [Link]

If running processes have files open which have been removed from their original *directories* and replaced by new files at the same pathnames by package updates, the old *inodes* will still be in the *current* filesystem until such time as the running processes close the files.

This 'just works' even in the absence of snapshots.

With snapshots, it means the disk space in question won't be reclaimable when old snapshots are removed, but it won't stop the snapshots themselves from being removed. The space will become reclaimable only when the data is no longer in use -- i.e. when the inode is no longer open in the live, mounted filesystem.

Btrfs for Rawhide users?

Posted Nov 22, 2009 16:47 UTC (Sun) by anton (subscriber, #25547) [Link]

Yes, for most applications you will probably have to shut them down before switching a file system from one snapshot to another one. You usually don't have to do that when you do a snapshot, because (if Btrfs gets it right) the snapshot will represent some state that logically existed during the execution of the application. When you recover from that snapshot, it's as if the application was killed or crashed by itself at that point, and the application should be able to recover from that. For upgrades the package management system and the scripts for the application package tend to perform whatever shutdowns and restarts are necessary for the particular package (at least that's my experience in Debian, don't know about Fedora).

Of course, only covering one file system can pose a consistency problem if the application distributes its data across several file systems. It would be cool if one could snapshot all file systems at the same (logical) time.