On Thursday 26 March 2009 18:52:07 Jonathan Dieter wrote: ... > My experience with lvm snapshotting was that it slowed down disk speeds > significantly. I would expect that filesystem based snapshotting (which > btrfs will have) might be more efficient. Or we could make sure the > snapshot is only left long enough to make sure the updates work. You're basically doing copy-on-write of lots of metadata on the disk when you start doing anything that writes to it. Once that happens, new blocks can get reused in place for future updates and that slowdown should disappear. Making sure you have "noatime" in the mount options might help. Any other way of doing this - "creating a rollback" - is going to involve at least as much writing of data to disk *somewhere* and the hit will come all at once while doing the updates. You also make your update tools etc much more complex, which isn't necessarily a good thing. LVM snapshots will also cope with most of the issues surrounding changing config file formats, and so on; the drawback is that you would need enough disk space to store two copies of any substantial data files that might change. This isn't unique to taking a snapshot; you'd again use just as much space and probably time taking a backup of a big database, for example, and you'd have to do that anyway if you were upgrading postgresql from <8.3.1 to 8.3.x, ... -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
