From: Nataraj <incoming-redhat@rjl.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] Snapshots and disk re-use
Date: Wed, 23 Feb 2011 11:49:01 -0800 [thread overview]
Message-ID: <4D6564AD.9040605@rjl.com> (raw)
In-Reply-To: <4D655459.6050806@gmail.com>
On 02/23/2011 10:39 AM, Les Mikesell wrote:
> On 2/23/2011 12:19 PM, Jonathan Tripathy wrote:
>>
>>>> So you're not worried about the security implication of leftovers in
>>>> free
>>>> space, and just want a base image to clone for new customers?
>>>>
>>>> The logical thing to do is to keep the origin volume untouched (except
>>>> for upgrading now and then), and take a snapshot for each customer.
>>>> Each snapshot would then be a new clone of the origin. Unfortunately,
>>>> large numbers of snapshots are inefficient for writes to new data,
>>>> so you'd likely have to "dd" to an independent LV instead. (This is
>>>> being
>>>> worked on, and there are 3rd party products like Zumastor that fix it
>>>> now.)
>>> Actually, if you never (or rarely) write to the origin, lots of
>>> snapshots
>>> should be fine.
>>
>>> But every write to the origin will first copy the
>>> original origin data to every snapshot.
>>>
>> Why would origin data be copied over to the snapshot after the snapshot
>> has been created? Surely the point of a snapshot is to have "frozen"
>> data?
The content of the snapshot is not changing. Previously the data in the
snapshot was a pointer to the origin. When you rewrite data in the
origin, the old data gets moved to the cow device which is owned by the
snapshot, not by the origin. So the view of the snapshot does not
change, only that for the underlying data that was changed in the
origin, the previous data is moved to the snapshot's cow and now the
snapshot points to that data in the cow instead of in the origin volume.
I would be careful of using the word frozen, because you can actually
make changes to the snapshot volume if you wanted to, so it is not
really frozen.
>
> Yes, is the way this actually works explained somewhere? I would have
> expected the 'copy-on-write' blocks to be copied only on the side
> where the write is happening and relocated instead of rewriting all
> the snapshots that might be outstanding with the old data.
>
I don't know for sure, but it sounds like it is currently done this
way. Ideally there could be some kind of data sharing between multiple
snapshots. I suspect the data gets copied (instead of just changing
pointers) to avoid excessive fragmentation in the origin volume.
Nataraj
next prev parent reply other threads:[~2011-02-23 19:49 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 12:36 [linux-lvm] Snapshots and disk re-use Jonathan Tripathy
2011-02-23 13:09 ` Joe Thornber
2011-02-23 13:57 ` Jonathan Tripathy
2011-02-23 14:16 ` Joe Thornber
2011-02-23 14:18 ` Jonathan Tripathy
2011-02-23 16:12 ` Ray Morris
2011-02-23 16:55 ` Jonathan Tripathy
2011-02-23 17:54 ` Stuart D. Gathman
2011-02-23 18:05 ` Jonathan Tripathy
2011-02-23 19:34 ` Stuart D. Gathman
2011-02-23 18:05 ` Stuart D. Gathman
2011-02-23 18:19 ` Jonathan Tripathy
2011-02-23 18:39 ` Les Mikesell
2011-02-23 19:39 ` Stuart D. Gathman
2011-02-23 20:03 ` Les Mikesell
2011-02-23 20:37 ` Stuart D. Gathman
2011-02-23 20:49 ` Jonathan Tripathy
2011-02-23 23:25 ` Stuart D. Gathman
2011-02-23 23:42 ` Stuart D. Gathman
2011-02-24 0:09 ` Jonathan Tripathy
2011-02-24 0:32 ` Stuart D. Gathman
2011-02-24 0:37 ` Jonathan Tripathy
2011-02-24 0:40 ` Jonathan Tripathy
2011-02-24 2:00 ` Stuart D. Gathman
2011-02-24 7:33 ` Jonathan Tripathy
2011-02-24 14:50 ` Stuart D. Gathman
2011-02-24 14:57 ` Jonathan Tripathy
2011-02-24 15:13 ` Stuart D. Gathman
2011-02-24 15:20 ` Jonathan Tripathy
2011-02-24 16:41 ` Jonathan Tripathy
2011-02-24 19:15 ` Nataraj
2011-02-24 19:25 ` Les Mikesell
2011-02-24 19:55 ` Stuart D. Gathman
2011-02-24 19:19 ` Stuart D. Gathman
2011-02-24 19:45 ` Stuart D. Gathman
2011-02-24 21:22 ` Jonathan Tripathy
2011-04-05 20:09 ` Jonathan Tripathy
2011-04-05 20:41 ` Stuart D. Gathman
2011-04-05 20:48 ` Jonathan Tripathy
2011-04-05 20:59 ` James Hawtin
2011-04-05 21:36 ` Jonathan Tripathy
2011-04-05 22:42 ` James Hawtin
2011-04-05 22:52 ` Jonathan Tripathy
2011-04-05 23:11 ` James Hawtin
2011-04-05 23:19 ` Jonathan Tripathy
2011-04-05 23:39 ` James Hawtin
2011-04-06 0:00 ` Jonathan Tripathy
2011-04-06 0:08 ` Stuart D. Gathman
2011-04-06 0:14 ` Jonathan Tripathy
2011-04-06 0:16 ` James Hawtin
2011-04-06 0:28 ` Jonathan Tripathy
2011-04-06 0:38 ` Stuart D. Gathman
2011-04-06 0:43 ` Stuart D. Gathman
2011-04-06 1:36 ` James Hawtin
2011-04-06 1:47 ` Jonathan Tripathy
2011-04-06 1:53 ` James Hawtin
2011-04-06 0:47 ` Jonathan Tripathy
2011-04-06 0:42 ` James Hawtin
2011-04-06 0:50 ` Jonathan Tripathy
2011-04-06 1:20 ` James Hawtin
2011-04-06 1:45 ` Jonathan Tripathy
2011-02-23 19:49 ` Nataraj [this message]
2011-02-23 19:24 ` Stuart D. Gathman
2011-02-23 19:07 ` [linux-lvm] Problem executing lvm related commands Tinni
2011-02-23 19:33 ` [linux-lvm] Snapshots and disk re-use Phillip Susi
2011-02-23 19:45 ` Stuart D. Gathman
2011-02-23 19:56 ` Nataraj
2011-02-23 13:18 ` Sunil_Gupta2
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D6564AD.9040605@rjl.com \
--to=incoming-redhat@rjl.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).