Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, 14 Feb 2008, Tomasz Chmielewski wrote: >>>> Here, it tells LVM2 can be used for creating snapshots. >>> >>> Caution: LVM2 snapshots become very slow if the amount of changes >>> increases due copy-on-write. Add the additional seeks and you have a much >>> lower write speed left. >>> The last time I tried it reduced the write speed to 15% of the normal >>> throughput. >> >> Indeed, and the more snapshots you have, the worse it gets, because the >> overwritten data has to be copied to each of the snapshots, since they are >> just sparse undo logs. > > This might get interesting one day: > > http://www.zumastor.org/ > > http://zumastor.googlecode.com/svn/trunk/doc/zumastor-howto.html#_snapshots > > 2.1. Snapshots > > Snapshots can be useful as part of an hourly backup system. Instead of > shutting down all applications for the entire duration of the backup, you can > shut them down for just the second or two needed to take a snapshot. Which doesn't solve the original poster's problem of having to shut things down for a consistent snapshot. :-( > If your goal is to protect users from accidental deletion of files, you may > want to take snapshots every hour, and leave the last few snapshots around; > users who accidentally delete a file can just look in the snapshot. There are much better ways of achieving this functionality. Snapshots are not the way to do it. A stackable versioning file system like Wayback (deprecated) and CopyFS achieve that in a much neater way. > LVM already lets administrators create snapshots, but its design has the > surprising property that every block you change on the original volume > consumes one block for each snapshot. The resulting speed and space penalty > usually makes the use of more than one or two snapshots at a time > impractical. > > Zumastor keeps all snapshots for a particular volume in a common snapshot > store, and shares blocks the way one would expect. Thus making a change to > one block of a file in the original volume only uses one block in the > snapshot store no matter how many snapshots you have. So it uses cascaded snapshots rather than parallel snapshots. Gordan