Btrfs for Rawhide users?

Posted Nov 19, 2009 13:55 UTC (Thu) by masoncl (subscriber, #47138)
In reply to: Btrfs for Rawhide users? by jimparis
Parent article: Btrfs for Rawhide users?

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.