* [linux-lvm] rw-snapshot as an addition for lvm
@ 2001-07-28 16:27 Anders Henke
2001-07-30 9:57 ` Joe Thornber
0 siblings, 1 reply; 4+ messages in thread
From: Anders Henke @ 2001-07-28 16:27 UTC (permalink / raw)
To: linux-lvm
Hi,
Currently, you take a snapshot from a logical volume and define a bufferlimit
after which the snapshot becomes invalid. As long as this limit has not
been reached, the snapshot is mountable as a readonly device.
Since journaled filesystems see a unclean fs, they do want to replay
their journal - which currently fails if the fs has not been prepared for
exactly this case where their unclean fs resides on a readonly-volume.
I think it's also quite interesting to have a rw-snapshot in which changes
of both real and snapshot are being written to a smaller bufferspace on disk:
the snapshot always represents the state of the LV when taking the snapshot,
but permits changes on 'its copy'.
However, if you're changing data on snapshot or original lv, this bufferspace
has to be used to keep the snapshot 'old' (to the time of snapshotting the lv)
as well as current (when you're writing to your snapshot). When the bufferspace
fills up, the snapshot has to return a 'disk full'-error at some point and
finally becomes invalid when too much data has been altered.
With such a function you might
-replay a journaled fs without changes for the journaled fs.
So if I want to use a snapshot for backup, I don't have to
take down the fs before snapshotting it or applying patches
to a kernel release you don't yet prefer on your systems.
-put a snapshotted database back online and perform e.g. perform
additional integrity checks (if the system really came down clean before
the snapshot has been performed or you've just a bad timing) before doing
a tape backup of the snapshots files.
-doing 'critical' or development work on a testbed without altering the
original system, e.g. test if e2fsck will unlink your critical files or
you'd better try to copy them from the unclean fs.
Or just to learn 'how can I manually try to recover this system in case
the vendor-supplied check fails'.
What do you think about such a system?
Anders
--
Schlund + Partner AG System Administration and Security
Erbprinzenstrasse 4-12 v://49.721.91374.50
D-76133 Karlsruhe f://49.721.91374.212
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] rw-snapshot as an addition for lvm
2001-07-30 9:57 ` Joe Thornber
@ 2001-07-30 9:28 ` Jos Visser
2001-07-30 10:46 ` Joe Thornber
0 siblings, 1 reply; 4+ messages in thread
From: Jos Visser @ 2001-07-30 9:28 UTC (permalink / raw)
To: linux-lvm
The question I would have is whether rw-snapshots (or, snapshots in
general), should be implemented in LVM or as a separate driver/layer. In
that case, a snapshot could be taken of any block device, not only of a
logical volume.
Another interesting feature that I might add that would be handy here is
the "dynamic LV". This would be a LV that can extend dynamically if so
requested. The advantage of this would be that you could use the dynamic
LV as the buffer space of a snapshot. If the snapshot requires more
space, the LV could extend dynamically to allow for this....
++Jos
And thus it came to pass that Joe Thornber wrote:
(on Mon, Jul 30, 2001 at 10:57:26AM +0100 to be exact)
> On Sat, Jul 28, 2001 at 06:27:41PM +0200, Anders Henke wrote:
> > I think it's also quite interesting to have a rw-snapshot in which changes
> > of both real and snapshot are being written to a smaller bufferspace on disk:
> > the snapshot always represents the state of the LV when taking the snapshot,
> > but permits changes on 'its copy'.
>
> See other thread in the last few days on rw snapshots; Yes, it's an
> execellent idea.
>
> - Joe
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
--
Im verzeihen des Unverzeihlichen ist der Mensch der gottlichen Liebe am n�chtsten.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] rw-snapshot as an addition for lvm
2001-07-28 16:27 [linux-lvm] rw-snapshot as an addition for lvm Anders Henke
@ 2001-07-30 9:57 ` Joe Thornber
2001-07-30 9:28 ` Jos Visser
0 siblings, 1 reply; 4+ messages in thread
From: Joe Thornber @ 2001-07-30 9:57 UTC (permalink / raw)
To: linux-lvm
On Sat, Jul 28, 2001 at 06:27:41PM +0200, Anders Henke wrote:
> I think it's also quite interesting to have a rw-snapshot in which changes
> of both real and snapshot are being written to a smaller bufferspace on disk:
> the snapshot always represents the state of the LV when taking the snapshot,
> but permits changes on 'its copy'.
See other thread in the last few days on rw snapshots; Yes, it's an
execellent idea.
- Joe
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] rw-snapshot as an addition for lvm
2001-07-30 9:28 ` Jos Visser
@ 2001-07-30 10:46 ` Joe Thornber
0 siblings, 0 replies; 4+ messages in thread
From: Joe Thornber @ 2001-07-30 10:46 UTC (permalink / raw)
To: linux-lvm
On Mon, Jul 30, 2001 at 11:28:18AM +0200, Jos Visser wrote:
> The question I would have is whether rw-snapshots (or, snapshots in
> general), should be implemented in LVM or as a separate driver/layer. In
> that case, a snapshot could be taken of any block device, not only of a
> logical volume.
Yes, I've already raised this issue... and written a new standalone
driver, which will go into experimental soon :) There's a similar
argument that multi-pathing is standalone.
>
> Another interesting feature that I might add that would be handy here is
> the "dynamic LV". This would be a LV that can extend dynamically if so
> requested. The advantage of this would be that you could use the dynamic
> LV as the buffer space of a snapshot. If the snapshot requires more
> space, the LV could extend dynamically to allow for this....
There are facilities for monitoring snapshot usage. You could easily
write a script that extends the lv when it hits, say, 90 % full.
- Joe
>
> ++Jos
>
> And thus it came to pass that Joe Thornber wrote:
> (on Mon, Jul 30, 2001 at 10:57:26AM +0100 to be exact)
>
> > On Sat, Jul 28, 2001 at 06:27:41PM +0200, Anders Henke wrote:
> > > I think it's also quite interesting to have a rw-snapshot in which changes
> > > of both real and snapshot are being written to a smaller bufferspace on disk:
> > > the snapshot always represents the state of the LV when taking the snapshot,
> > > but permits changes on 'its copy'.
> >
> > See other thread in the last few days on rw snapshots; Yes, it's an
> > execellent idea.
> >
> > - Joe
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@sistina.com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>
> --
> Im verzeihen des Unverzeihlichen ist der Mensch der gottlichen Liebe am ndchtsten.
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-07-30 10:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-07-28 16:27 [linux-lvm] rw-snapshot as an addition for lvm Anders Henke
2001-07-30 9:57 ` Joe Thornber
2001-07-30 9:28 ` Jos Visser
2001-07-30 10:46 ` Joe Thornber
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.