[lvm-devel] [PATCH - v2] LVM: New flag, LV_REBUILD

Jonathan Brassow jbrassow at redhat.com
Fri Nov 18 16:05:26 UTC 2011


On Nov 16, 2011, at 2:06 PM, Zdenek Kabelac wrote:

> Dne 14.11.2011 19:06, Jonathan Brassow napsal(a):
>> Changes from previous:
>> - New rebuild flag is now written to on-disk LVM metadata
>> - An additional metadata write/commit is necessary to clear the flag
>> after a proper resume
>> - flags.c file updated
>> 
>>  brassow
>> 
>> Add new flag, LV_REBUILD.
>> 
>> Until now, I had been using the LV_NOTSYNCED as a flag to indicate that RAID
>> sub-LVs needed to be rebuilt.  (The 'rebuild' parameter is then specified in
>> the DM CTR table.)  However, I don't want to use a flag that gets written to
>> the LVM metadata... and the LV_NOTSYNCED flag's original meaning does not
>> suite the purpose adequately.
>> 
>> This patch proposes and uses a new flag, LV_REBUILD.
> 
> Hmm so now - when it's written to disk - it looks like  LV_REBUILD and LV_NOTSYNCED is mostly the same meaning - except  one is used in raid
> and original in mirror ?
> 
> So I think it's easier to keep just one flag ?
> (Well the bit field space is somewhat limited)

Perhaps.  I've considered this and certainly it'd be easy for me to leave things the way they are.  However, LV_NOTSYNCED means that the LV was created (or extended) with '--nosync', and signifies that it has not and will not undergo a complete synchronization.  LV_REBUILD, on the other hand, means precisely the opposite - the LV is to undergo a complete synchronization now.  LV_NOTSYNCED signifies an attribute of the LV, while LV_REBUILD signifies an action that needs to be taken.

The only reason the difference is not more obvious is because you can look at 'LV_NOTSYNCED' sideways and sort-of make it work.  "These sub-LVs are not in-sync right now, and must be made to be in-sync." - or some similar thinking could get you there.

I'm good either way, but I'd prefer the new flag...

 brassow




More information about the lvm-devel mailing list