From: Mike Snitzer <snitzer@redhat.com>
To: lvm-devel@redhat.com
Subject: Re: [PATCH 02/15] lvm-merge-metadata
Date: Mon, 23 Nov 2009 09:30:58 -0500 [thread overview]
Message-ID: <20091123143058.GA11479@redhat.com> (raw)
In-Reply-To: <4B09A261.9020302@redhat.com>
On Sun, Nov 22 2009 at 3:43pm -0500,
Zdenek Kabelac <zkabelac@redhat.com> wrote:
> Dne 21.11.2009 03:06, Mike Snitzer napsal(a):
> > On Fri, Nov 20 2009 at 6:26pm -0500,
> > Zdenek Kabelac <zkabelac@redhat.com> wrote:
> >
> >> Dne 20.11.2009 23:35, Mike Snitzer napsal(a):
> >>> From: Mikulas Patocka <mpatocka@redhat.com>
> >>>
> >>> Add 'SNAPSHOT_MERGE' lv_segment 'status' flag.
> >>>
> >>> Make 'merging_snapshot' pointer that points from the origin to the
> >>> segment that represents the merging snapshot.
> >>>
> >>> Import/export 'merging_store' metadata.
> >>>
> >>> Do not allow creating snapshots while another snapshot is merging.
> >>> Snapshot created in this state would certainly contain invalid data.
> >>>
> >>> diff --git a/lib/metadata/metadata-exported.h b/lib/metadata/metadata-exported.h
> >>> index e9a3d5d..30073d3 100644
> >>> --- a/lib/metadata/metadata-exported.h
> >>> +++ b/lib/metadata/metadata-exported.h
> >>> @@ -60,6 +60,7 @@
> >>> //#define ACTIVATE_EXCL 0x00100000U /* LV - internal use only */
> >>> //#define PRECOMMITTED 0x00200000U /* VG - internal use only */
> >>> #define CONVERTING 0x00400000U /* LV */
> >>> +#define SNAPSHOT_MERGE 0x00800000U /* SEG */
> >>>
> >>> #define MISSING_PV 0x00800000U /* PV */
> >>
> >> I think reusing these bitfields might lead to unexpected troubles.
> >
> > Nice catch, surprised I missed that.
> >
> > Looks like I'll go with:
> > #define SNAPSHOT_MERGE 0x10000000U
> >
>
> Yes - one small step for you :), but we run out-of-bits here - for replicator
> I've tried to reduces bit usage just for 2 bits (instead of using separate bit
> for _rimage, _rlog, _slog, replicator-dev) - but together with crypto we are
> out-of-space.
>
> So either we might switch to 64bit status (simple) - or use some solution
> based on function calls instead of bit checks.
Right, I think we should just switch to 64-bit status.
Mike
next prev parent reply other threads:[~2009-11-23 14:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-20 22:35 [PATCH 00/15] lvm2 support for snapshot-merge Mike Snitzer
2009-11-20 22:35 ` [PATCH 01/15] use snapshot metadata usage to determine if snapshot is empty Mike Snitzer
2009-11-20 22:35 ` [PATCH 02/15] lvm-merge-metadata Mike Snitzer
2009-11-20 23:26 ` Zdenek Kabelac
2009-11-21 2:06 ` Mike Snitzer
2009-11-22 20:43 ` Zdenek Kabelac
2009-11-23 14:30 ` Mike Snitzer [this message]
2009-11-23 14:37 ` Alasdair G Kergon
2009-11-20 22:35 ` [PATCH 03/15] Add support for "snapshot-merge" target Mike Snitzer
2009-11-20 22:35 ` [PATCH 04/15] device-mapper-merge-activation Mike Snitzer
2009-11-20 22:35 ` [PATCH 05/15] device-mapper-merging-store-needs-cow-suffix Mike Snitzer
2009-11-20 22:35 ` [PATCH 06/15] lvm-merge-lvconvert Mike Snitzer
2009-11-20 22:35 ` [PATCH 07/15] lvm-merge-check-for-mounted-lv Mike Snitzer
2009-11-20 22:35 ` [PATCH 08/15] lvm-merge-reporting Mike Snitzer
2009-11-20 22:35 ` [PATCH 09/15] lvm-merge-origin-report-progress Mike Snitzer
2009-11-20 22:35 ` [PATCH 10/15] lvm-merge-background-poll Mike Snitzer
2009-11-20 22:35 ` [PATCH 11/15] lvm-merge-background-poll-on-lvvgchange Mike Snitzer
2009-11-20 22:35 ` [PATCH 12/15] lvm-merge-reload-if-stopped-merging Mike Snitzer
2009-11-20 22:35 ` [PATCH 13/15] lvm-merge-reload-proper-order Mike Snitzer
2009-11-20 22:35 ` [PATCH 14/15] lvm-merge-onactivate Mike Snitzer
2009-11-20 22:35 ` [PATCH 15/15] lvm-merge-man-lvconvert Mike Snitzer
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=20091123143058.GA11479@redhat.com \
--to=snitzer@redhat.com \
--cc=lvm-devel@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 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.