[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evms-devel
Subject:    Re: [Evms-devel] Proposal: Change in initrd
From:       Steve Dobbelstein <steved () us ! ibm ! com>
Date:       2005-02-17 15:44:00
Message-ID: OF50C505FC.C2B5E878-ON06256FAB.005644CB-06256FAB.00566D21 () us ! ibm ! com
[Download RAW message or body]





kevcorry@us.ltcfwd.linux.ibm.com wrote on 02/17/2005 08:34:53 AM:

> On Wed February 16 2005 4:11 pm, Michel Bouissou wrote:
> > Le Mercredi 16 Février 2005 21:30, Steve Dobbelstein a écrit :
> > > Correct me if I'm wrong.  Doesn't the snapshot code build the
associated
> > > object pointers such that when the origin volume is scheduled to be
> > > activated the snapshot object gets activated as well?  If the linuxrc
> > > script modifies evms.conf so that it says "include = [
> > > /dev/evms/root_volume ] then the Engine should figure out all the
objects
> > > that need to be activated in order to activate the root volume.  The
> > > snapshot(s) of the root volume should also be scheduled to be
activated.
> > > Correct?
> >
> > No, the snapshot isn't activated. (And I wouldn't want it to be, so
IMHO
> > this behaviour is "good").
>
> No, in my opinion that's the wrong behavior. If a user has a
> snapshot of their
> root volume and they reboot the system, the snapshot is supposed to still
be
> valid after the system boots. By activating the origin without activating
the
> snapshot, the snapshot is no longer valid.
>
> > I have a snapshot on my root fs, and the snapshot resides in another
LVM
> > container made on another RAID-set, so I'm happy with the fact that
> > activating only the root volume doesn't activate the snapshot (because
it
> > would then activate the other MD set which I don't want active at this
> > time).
>
> After reading through the code a bit
> (plugins/snapshot/snapshot.c::snap_activate()), when the origin gets
> activated, it checks each of its snapshots to see if they are also marked
for
> activation. If one isn't, the header on that snapshot is forceably
erased,
> effectively resetting the snapshot the next time it is activated. So
while
> this might be the behavior you want to see following a reboot, I'm not
sure
> that all EVMS users are going to agree on this.
>
> In fact, if we can find a way to have evms_activate mark the snapshots of
the
> desired volume for activation, I think that should be the default
behavior,
> since it's quite simple to later reset the snapshots if that's what the
user
> desires. It would also be possible (assuming the aforementioned change to

> evms_activate is possible) to add a --no-snapshots option that would
disable
> this search in evms_activate for the snapshots of the desired volume, and
go
> ahead with activating the volume and thus resetting the snapshots. Then
we
> could add another kernel command-line argument that the initrd could
search
> for and use this extra option if desired.
>
> How does this sound?

Looks to me like it should work.  I like it.

Steve D.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&opÌk
_______________________________________________
Evms-devel mailing list
Evms-devel@lists.sourceforge.net
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel

[prev in list] [next in list] [prev in thread] [next in thread]