Messages in this thread | | | Date | Wed, 23 May 2001 10:23:44 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup) |
| |
Hi,
On Tue, May 22, 2001 at 02:59:32PM -0600, Peter J. Braam wrote:
> But during recovery, LVM cannot possibly know if the whole process of > copying out the data from the current to the snapshot area completed > during the previous run. Yes, LVM updates the redirection table first and > then copies, but, still, you don't know _where exactly_ the writes stopped > happening and in particular you don't know if the block was copied already > or not.
LVM updates the snapshot redirection without knowing that the new redirection location has been written? So if I write to a LVM snapshot and take a crash, I might not actually get either the old or the new data, but in fact some previous random contents of a new block? Eek. Journaling will not like that. Databases won't like that. Anything that relies on fsync to ensure some write ordering on disk will be potentially upset by that.
> It's better to keep the snapshot in the old volume and write the new data > to a separate area (that's what most commercial systems do I think).
No. The commercial systems write snapshots to a new area, usually. There are two very good reason for that --- when you come to delete a snapshot, there's no IO involved; and you avoid fragmenting the original root volume.
In systems I'm familiar with, the copy-out is always done in the same direction with the snapshot getting the new block. This even happens if the snapshot is writable: regardless of whether it is the snapshot or the root being written, the copy-out always results in the snapshot getting moved, not the root.
Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |