From: Greg Freemyer <freemyer-ml@NorcrossGroup.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] LVM Snapshots for remote archiving.
Date: Wed Jan 28 12:33:01 2004 [thread overview]
Message-ID: <1075310348.25365.43.camel@david.internal.NorcrossGroup.com> (raw)
In-Reply-To: <4017E699.5020703@gene.concordia.ca>
On Wed, 2004-01-28 at 11:43, Chris Beck wrote:
> I guess I am misunderstanding how a snapshot volume works, I kinda
> thought it would be this mythical transaction log - disk writes need to
> be stored somewhere while the original volume is frozen and I was hoping
> that I could move the whole thing around like any other file.
>
> I was hoping to avoid rsync/rdiff because the snapshot volume itself was
> a list of differences over the last 24 hours.
>
> It is whispered that Greg Freemyer was heard, on or about 1/27/2004 6:29
> PM to say:
>
A snapshot is based on copy on write technology. I guess you could use
it to create the transaction log you are talking about, but it is not
what it is designed to do, and I believe significant effort would be
involved.
Basically with a snapshot, a blank disk volume is created with a flag
table with one entry per block of master volume data. All of the flag
entries are initialized as "unmodified".
When a write is performed to the master volume, the flag table is
checked. If the flag for that particular block is set to "unmodified",
then a copy of the unmodified block is made to the snapshot area prior
to the write being performed. The flag is then set to modified.
Future writes to that specific block will have no effect on the flag
table, nor on the snapshot volume.
For your transaction log, the flag table is significant, but the actual
snapshot volume is not. It is just the old unmodified content.
To get a true set of differences over a 24-hour period, you would have
to create a snapshot at time T, and another at time T+24. (Easily done
I think).
Then have code that went thru the flag table for snapshot T and
retrieved the blocks from snapshot T+24 that were marked as modified.
(LVM will automatically get the block from the appropriate source: T+24
or Master volume)
Once done, the snapshot T would be deleted, and snapshot T+24 would be
maintained. At the 48 hour mark, snapshot T+48 would be created and the
process repeated.
I don't think that is a trivial issue, and I think the code would have
to implemented in the kernel.
New code would also have to be developed to apply the above blocks.
HTH
Greg
--
Greg Freemyer
next prev parent reply other threads:[~2004-01-28 12:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-27 18:05 [linux-lvm] LVM Snapshots for remote archiving Chris Beck
2004-01-27 18:46 ` Greg Freemyer
2004-01-28 11:44 ` Chris Beck
2004-01-28 12:33 ` Greg Freemyer [this message]
2004-01-28 14:06 ` Chris Beck
2004-01-29 11:52 ` Greg Freemyer
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=1075310348.25365.43.camel@david.internal.NorcrossGroup.com \
--to=freemyer-ml@norcrossgroup.com \
--cc=linux-lvm@sistina.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.