Skip to contentSkip to conversation

relocate on write for snapshot

linux-lvm Ming Zhang 3 participants 4 messages Nov 19, 2004

lore
Share & tools
lore

Ming Zhang

author
#0 lore raw

Hi, I wonder if there are any thought about a relocate on write policy for snapshot instead of copy on write policy used now?

instead of copy old one to snapshot, overwrite old one with new one, 2 writes and 1 reads. it is possible that write new data to a usused location directly.

i know later remove a snaphot will be a little trouble, but there must be some way to get around it.

just a rough thought, any comment?

ming

#1 lore raw
Quoted 12 lines · Ming Zhang

Hi, I wonder if there are any thought about a relocate on write policy for snapshot instead of copy on write policy used now?

instead of copy old one to snapshot, overwrite old one with new one, 2 writes and 1 reads. it is possible that write new data to a usused location directly.

i know later remove a snaphot will be a little trouble, but there must be some way to get around it.

just a rough thought, any comment?

I thought the way it worked now was for snapshot LV to be marked as the "active destination" for all new writes to the logical volume. On write, the data isn't copied, just the metadata is changed to reflect which physical extent the block is now located on, and the old one is then reallocated as part of the snapshot.

Am I wrong?

Signature · 1 line
Clint Byrum <[email protected]>
#2 lore raw
In reply to Ming Zhang
Quoted 3 lines · Ming Zhang

instead of copy old one to snapshot, overwrite old one with new one, 2 writes and 1 reads. it is possible that write new data to a usused location directly.

Since you have to delete the snapshot (and I don't think they live very long on most systems) you don't gain anything (because you have copy the changes back from the snapshot), but you make the cases of more than one snapshot and (possibly) read-write snapshots a lot harder, maybe not in CPU or IO, but certainly in code complexity, which is a thing you never do to gain a bit of performance.

Quoted 2 lines

i know later remove a snaphot will be a little trouble, but there must be some way to get around it.

Yes, you have to do the work you saved a couple of minutes earlier :)

just my EUR 0.02,
Nils

Signature · 3 lines
Nils Juergens  | [email protected] | icq 7090774
Having problems sending big files over the net?
Try out Efisto (http://efisto.org).
author
#3 lore raw
Quoted 6 lines · Nils Juergens
Quoted 3 lines · Ming Zhang

instead of copy old one to snapshot, overwrite old one with new one, 2 writes and 1 reads. it is possible that write new data to a usused location directly.

Quoted 7 lines

Since you have to delete the snapshot (and I don't think they live very long on most systems) you don't gain anything (because you have copy the changes back from the snapshot), but you make the cases of more than one snapshot and (possibly) read-write snapshots a lot harder, maybe not in CPU or IO, but certainly in code complexity, which is a thing you never do to gain a bit of performance.

on some systems that mainly for disaster recovery purpose, there will be a lot of snapshots available for a lv. this can make the recovery much easier.

Quoted 5 lines
Quoted 2 lines

i know later remove a snaphot will be a little trouble, but there must be some way to get around it.

Yes, you have to do the work you saved a couple of minutes earlier :)

a dedicated snapshot merge process can solve this.

Quoted 1 line

just my EUR 0.02,

thanks. discussion always can make thing clarified.

Quoted 1 line

Nils