Btrfs snapshots proposal —
I’ve written up a feature proposal on how we can use Btrfs snapshots to enable system rollbacks in Fedora 13, by gluing together the existing kernel code to do Btrfs snapshots, a UI for performing rollbacks, and a yum plugin to make snapshots automatically before each yum transaction. Lots of good comments so far, and LWN has written an article about it.
(Updated: The LWN link is no longer subscriber-only.)
That would be so cool.
Do you know how far btrfs are feature and stability wise?
We haven’t heard much from Chris Mason lately.
Have you looked at the way OpenSolaris/ZFS does snapshot upgrades? It’s slightly different in that you snapshot, then upgrade the snapshot and reboot into the upgraded version. I’m commenting here because I’m too lazy to get a fedora account to comment on the wiki.
In the interest of a transparent discussion, could somebody post a subscriber link to that article ?
@James: that sound like a very robust way to go about things. You’d need to have two different snapshots mounted in two places at the same time, though. Not sure BTRFS (and linux VFS) can do that ATM.
> Do you know how far btrfs are feature and stability wise?
Features and stability are doing okay, but not ready to be the default filesystem in Fedora 13. There’s almost no ability to handle corrupted filesystems (e.g. fsck doesn’t really do anything yet), which is a deal-breaker for many people.
Yep, not too different. I think we’re going to end up with something very similar to Nexenta:
I don’t want to deprive LWN of subscriptions, so I’m not going to post a subscriber link to the thread, but I’ve e-mailed you one individually. (And will do so for other people if they ask.)
Wasn’t this discussed on the mailing list?
The problem is that we don’t have one partition for rpm-stuff, and one for everything else.
The second problem is that application data tends to be readable only by newer software, not older software: so if you upgrade mysql and it is unstable, you lose all the data you wrote to the database with the new version AS WELL AS all your data because the new data files cannot be read by the older version.
> The problem is that we don’t have one partition for rpm-stuff, and one for everything else.
I don’t think it’s a huge problem. We get to choose between the status quo of “your system gets hosed, you reformat” and the new feature of “your system gets hosed, you rollback to the last checkpoint and can manually bring files back from the hosed version if you need them”, and I think the new feature is an obvious improvement. It does not solve every problem for everyone, but that’s okay.
> so if you upgrade mysql and it is unstable, you lose all the data you wrote to the database with the new version AS WELL AS all your data because the new data files cannot be read by the older version.
(MySQL rarely changes its disk format for precisely this reason.)
Again, I think this is *better* than living in a world with no rollbacks: you upgrade, and everything breaks. Would you rather be totally screwed, or have the option of reverting to the world in which the upgrade had never happened, and at least getting your old data back? There’s no disadvantage to having the rollback feature, only potential advantages.
> I don’t want to deprive LWN of subscriptions, so I’m not going to post a subscriber link to the thread, but I’ve e-mailed you one individually. (And will do so for other people if they ask.)
This is considerate of you, but actually, LWN approve such subsciption links according to their FAQ:
> Where is it appropriate to post a subscriber link?
> Almost anywhere. Private mail, messages to project mailing lists, and weblog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared.
I guess they think the positive PR you give LWN by posting about one of their articles is greater than any negative effect of defeating the need for a subscription for this isolated article. I think they have made a good call.
Thanks, dash, I didn’t realize this. I agree; that’s a nice policy.
> (MySQL rarely changes its disk format for precisely this reason.)
mysql was an example. It applies to anything that stores data on disk.