FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 08-01-2008, 07:35 AM
"Bombardier, Pascal"
 
Default LVM Snapshot Feature

Hi,

In your opinion, does it make sense to be able to create non-persistent
snapshots ?
In the case of a filesystem backup, a non-persistent snapshot would be a
snapshot that we agree to lose in case of failure or reboot. If anything
happens, a server administrator would have to recreate a new snapshot
and then restart the backup.
In this case, I think metadata could be stored in memory instead of on
disk, which should improve LVM snapshot performance.

Is this theory wrong, and is this something which can be implemented
easily in the current LVM code ?

Pascal

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 08-01-2008, 02:15 PM
Luke S Crawford
 
Default LVM Snapshot Feature

"Bombardier, Pascal" <pascal.bombardier@sap.com> writes:
> In your opinion, does it make sense to be able to create non-persistent
> snapshots ?
> In the case of a filesystem backup, a non-persistent snapshot would be a
> snapshot that we agree to lose in case of failure or reboot. If anything
> happens, a server administrator would have to recreate a new snapshot
> and then restart the backup.

Considering the current failure mode when a snapshot becomes 'full' (that
is, when I run out of space to remap changed blocks the snapshot becomes
corrupted) this is the only way I currently feel comfortable using LVM
snapshots at all, so personally, I think snapshots that did not persist
through reboots would be quite useful.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 08-01-2008, 03:52 PM
Adam Hamsik
 
Default LVM Snapshot Feature

On Aug,Friday 1 2008, at 9:35 AM, Bombardier, Pascal wrote:


Hi,

In your opinion, does it make sense to be able to create non-
persistent

snapshots ?
In the case of a filesystem backup, a non-persistent snapshot would
be a
snapshot that we agree to lose in case of failure or reboot. If
anything

happens, a server administrator would have to recreate a new snapshot
and then restart the backup.
In this case, I think metadata could be stored in memory instead of on
disk, which should improve LVM snapshot performance.

Is this theory wrong, and is this something which can be implemented
easily in the current LVM code ?



AFAIK non-persistent snapshots are already implemented see
DM_PERSISTENT_DEV_FLAG ? I haven't look at linux kernel code how is
it done but when I solve my lvcreate -s bug on NetBSD non-persistent
snapshots are next .

Regards

Adam.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 08-04-2008, 01:15 PM
Mikulas Patocka
 
Default LVM Snapshot Feature

On Fri, 1 Aug 2008, Adam Hamsik wrote:

> On Aug,Friday 1 2008, at 9:35 AM, Bombardier, Pascal wrote:
>
> > Hi,
> >
> > In your opinion, does it make sense to be able to create non-persistent
> > snapshots ?
> > In the case of a filesystem backup, a non-persistent snapshot would be a
> > snapshot that we agree to lose in case of failure or reboot. If anything
> > happens, a server administrator would have to recreate a new snapshot
> > and then restart the backup.
> > In this case, I think metadata could be stored in memory instead of on
> > disk, which should improve LVM snapshot performance.
> >
> > Is this theory wrong, and is this something which can be implemented
> > easily in the current LVM code ?
> >
>
> AFAIK non-persistent snapshots are already implemented see
> DM_PERSISTENT_DEV_FLAG ? I haven't look at linux kernel code how is
> it done but when I solve my lvcreate -s bug on NetBSD non-persistent
> snapshots are next .
>
> Regards
>
> Adam.

Yes. They are implemented in device mapper in kernel --- but no userspace
lvm tool can use them. You can only create them using dmsetup.

Mikulas

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 08-06-2008, 06:08 AM
haad
 
Default LVM Snapshot Feature

On Mon, Aug 4, 2008 at 4:15 PM, Mikulas Patocka <mpatocka@redhat.com> wrote:
> On Fri, 1 Aug 2008, Adam Hamsik wrote:
>
>> On Aug,Friday 1 2008, at 9:35 AM, Bombardier, Pascal wrote:
>>
>> > Hi,
>> >
>> > In your opinion, does it make sense to be able to create non-persistent
>> > snapshots ?
>> > In the case of a filesystem backup, a non-persistent snapshot would be a
>> > snapshot that we agree to lose in case of failure or reboot. If anything
>> > happens, a server administrator would have to recreate a new snapshot
>> > and then restart the backup.
>> > In this case, I think metadata could be stored in memory instead of on
>> > disk, which should improve LVM snapshot performance.
>> >
>> > Is this theory wrong, and is this something which can be implemented
>> > easily in the current LVM code ?
>> >
>>
>> AFAIK non-persistent snapshots are already implemented see
>> DM_PERSISTENT_DEV_FLAG ? I haven't look at linux kernel code how is
>> it done but when I solve my lvcreate -s bug on NetBSD non-persistent
>> snapshots are next .
>>
>> Regards
>>
>> Adam.
>
> Yes. They are implemented in device mapper in kernel --- but no userspace
> lvm tool can use them. You can only create them using dmsetup.
>
> Mikulas


Do you have list of commands which I have to run to create persistent dm
snapshot with dmsetup ? It would be handy to test my driver with dmsetup
first and only after that use lvm2tools to create persistent/non-persistent
snapshots.

Regards

Adam.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 10:13 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org