Linux LVM users
 help / color / mirror / Atom feed
* [linux-lvm] relocate on write for snapshot
@ 2004-11-19 16:39 Ming Zhang
  2004-11-19 17:05 ` Clint Byrum
  2004-11-19 17:19 ` Nils Juergens
  0 siblings, 2 replies; 4+ messages in thread
From: Ming Zhang @ 2004-11-19 16:39 UTC (permalink / raw)
  To: linux-lvm

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [linux-lvm] relocate on write for snapshot
  2004-11-19 16:39 [linux-lvm] relocate on write for snapshot Ming Zhang
@ 2004-11-19 17:05 ` Clint Byrum
  2004-11-19 17:19 ` Nils Juergens
  1 sibling, 0 replies; 4+ messages in thread
From: Clint Byrum @ 2004-11-19 17:05 UTC (permalink / raw)
  To: mingz, LVM general discussion and development

On Fri, 2004-11-19 at 11:39 -0500, Ming Zhang wrote:
> 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?

-- 
Clint Byrum <cbyrum@spamaps.org>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [linux-lvm] relocate on write for snapshot
  2004-11-19 16:39 [linux-lvm] relocate on write for snapshot Ming Zhang
  2004-11-19 17:05 ` Clint Byrum
@ 2004-11-19 17:19 ` Nils Juergens
  2004-11-19 17:56   ` Ming Zhang
  1 sibling, 1 reply; 4+ messages in thread
From: Nils Juergens @ 2004-11-19 17:19 UTC (permalink / raw)
  To: linux-lvm

On Fri, 19.11.04, Ming Zhang <mingz@ele.uri.edu> wrote:

> 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.

> 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

-- 
Nils Juergens  | nils@muon.de | icq 7090774
Having problems sending big files over the net?
Try out Efisto (http://efisto.org).

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [linux-lvm] relocate on write for snapshot
  2004-11-19 17:19 ` Nils Juergens
@ 2004-11-19 17:56   ` Ming Zhang
  0 siblings, 0 replies; 4+ messages in thread
From: Ming Zhang @ 2004-11-19 17:56 UTC (permalink / raw)
  To: LVM general discussion and development

On Fri, 2004-11-19 at 12:19, Nils Juergens wrote:
> On Fri, 19.11.04, Ming Zhang <mingz@ele.uri.edu> wrote:
> 
> > 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.
> 
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.

> > 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.

> just my EUR 0.02,
thanks. discussion always can make thing clarified.


> Nils

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-11-19 17:57 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-19 16:39 [linux-lvm] relocate on write for snapshot Ming Zhang
2004-11-19 17:05 ` Clint Byrum
2004-11-19 17:19 ` Nils Juergens
2004-11-19 17:56   ` Ming Zhang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox