zeroing old superblocks & upgrading...

zeroing old superblocks & upgrading...

[John Stoffel]

Neil,

First off, thanks for all your hard work on this software, it's really
a great thing to have.

But I've got some interesting issues here.  Though not urgent.  As
I've said in other messages, I've got a pair of 120gb HDs mirrored.
I'm using MD across partitions, /dev/hde1 and /dev/hdg1.  Works
nicely.

But I see that I have an old superblock sitting around on /dev/hde
(notice, no partition here!) which I'd like to clean up.

    # mdadm -E /dev/hde
    /dev/hde:
	      Magic : a92b4efc
	    Version : 00.90.00
	       UUID : 9835ebd0:5d02ebf0:907edc91:c4bf97b2
      Creation Time : Fri Oct 24 19:11:02 2003
	 Raid Level : raid1
	Device Size : 117220736 (111.79 GiB 120.03 GB)
	 Array Size : 117220736 (111.79 GiB 120.03 GB)
       Raid Devices : 2
      Total Devices : 2
    Preferred Minor : 0

	Update Time : Fri Oct 24 19:21:59 2003
	      State : clean
     Active Devices : 1
    Working Devices : 1
     Failed Devices : 1
      Spare Devices : 0
	   Checksum : 79d2a6fd - correct
	     Events : 0.2


	  Number   Major   Minor   RaidDevice State
    this     0       3        0        0      active sync   /dev/hda

       0     0       3        0        0      active sync   /dev/hda
       1     1       0        0        1      faulty


Here's the correct ones:

    # mdadm -E /dev/hde1
    /dev/hde1:
	      Magic : a92b4efc
	    Version : 00.90.00
	       UUID : 2e078443:42b63ef5:cc179492:aecf0094
      Creation Time : Fri Oct 24 19:23:41 2003
	 Raid Level : raid1
	Device Size : 117218176 (111.79 GiB 120.03 GB)
	 Array Size : 117218176 (111.79 GiB 120.03 GB)
       Raid Devices : 2
      Total Devices : 2
    Preferred Minor : 0

	Update Time : Thu Jul  6 18:21:08 2006
	      State : clean
     Active Devices : 2
    Working Devices : 2
     Failed Devices : 0
      Spare Devices : 0
	   Checksum : 210069e5 - correct
	     Events : 0.7762540


	  Number   Major   Minor   RaidDevice State
    this     0      33        1        0      active sync   /dev/hde1

       0     0      33        1        0      active sync   /dev/hde1
       1     1      34        1        1      active sync   /dev/hdg1


I can't seem to zero it out:

  # mdadm --misc --zero-superblock /dev/hde
  mdadm: Couldn't open /dev/hde for write - not zeroing

Should I just ignore this, or should I break off /dev/hde from the
array and scrub the disk and then re-add it back in?

Also, can I upgrade my superblock to the latest version with out any
problems?

Thanks,
John

Re: zeroing old superblocks & upgrading...

[Neil Brown]

On Thursday July 6, john@stoffel.org wrote:
> 
> Neil,
> 
> First off, thanks for all your hard work on this software, it's really
> a great thing to have.
> 
> But I've got some interesting issues here.  Though not urgent.  As
> I've said in other messages, I've got a pair of 120gb HDs mirrored.
> I'm using MD across partitions, /dev/hde1 and /dev/hdg1.  Works
> nicely.
> 
> But I see that I have an old superblock sitting around on /dev/hde
> (notice, no partition here!) which I'd like to clean up.
> 
...
> 
> I can't seem to zero it out:
> 
>   # mdadm --misc --zero-superblock /dev/hde
>   mdadm: Couldn't open /dev/hde for write - not zeroing
> 
> Should I just ignore this, or should I break off /dev/hde from the
> array and scrub the disk and then re-add it back in?

You could ignore it - it shouldn't hurt.
But if you wanted to (and were running a fairly recent kernel) you
could
  mdadm --grow --bitmap=internal /dev/md0
  mdadm /dev/md0 --fail /dev/hde1 --remove /dev/hde1
  mdadm --zero-superblock /dev/hde
  mdadm /dev/md0 --add /dev/hde1
  mdadm --grow --bitmap=none /dev/md0

and it should work with minimal resync...

Though thinking about it - after the first --grow, check that the
unwanted bitmap is still there.  It is quite possible that the
internal bitmap will over-write the unwanted superblock (depending on
the exact size and aligment of hde1 compared with hde).
If it is gone, then don't bother with the rest of the sequence. 


> 
> Also, can I upgrade my superblock to the latest version with out any
> problems?

The only problem with superblock version numbers is that they are
probably confusing.  If you don't worry about them, they should just
do the right thing.

NeilBrown

Re: zeroing old superblocks & upgrading...

[John Stoffel]

>>>>> "Neil" == Neil Brown <neilb@suse.de> writes:

>> I can't seem to zero it out:
>> 
>> # mdadm --misc --zero-superblock /dev/hde
>> mdadm: Couldn't open /dev/hde for write - not zeroing
>> 
>> Should I just ignore this, or should I break off /dev/hde from the
>> array and scrub the disk and then re-add it back in?

Neil> You could ignore it - it shouldn't hurt.

Ok.

Neil> But if you wanted to (and were running a fairly recent kernel) you
Neil> could
Neil>   mdadm --grow --bitmap=internal /dev/md0

Did this.  And now I can do mdadm -X /dev/hde1 to examine the bitmap,
but I think this totally blows.  To create a bitmap, I add it to an
md# device, but to examine it, I have to know which sub-devices to
query?  That's really not what I would expect.

I do see that 

	mdadm -q --detail /dev/md0

shows the bitmap status (though not the size or parameters of the
bitmap), which is good. 

Neil>   mdadm /dev/md0 --fail /dev/hde1 --remove /dev/hde1
Neil>   mdadm --zero-superblock /dev/hde
Neil>   mdadm /dev/md0 --add /dev/hde1

Worked wonderfully!  Cleaned out the old superblock nicely, which I
think is a good thing here. 

Neil>   mdadm --grow --bitmap=none /dev/md0

Neil> and it should work with minimal resync...

So why would I want to remove the bitmap?  The re-sync happened pretty
much quickly enough that I didn't even see any non-in-sync status when
I did the --add of the device back in.  Very very cool...

Though... if I was paranoid, I'd disable the bitmap because there's no
way to be sure that I didn't write some garbage at a random block N
somewhere in the array.  Hmm... can't make that guarrentee now either,
so it's probably a moot point.  

In any case, I'm planning on keeping the bitmap.  

Neil> Though thinking about it - after the first --grow, check that
Neil> the unwanted bitmap is still there.  It is quite possible that
Neil> the internal bitmap will over-write the unwanted superblock
Neil> (depending on the exact size and aligment of hde1 compared with
Neil> hde).  If it is gone, then don't bother with the rest of the
Neil> sequence.

It was still there after the addition of the bitmap.  

Thanks Neil!

John

Re: zeroing old superblocks & upgrading...

[Neil Brown]

On Friday July 7, john@stoffel.org wrote:
> 
> Neil> But if you wanted to (and were running a fairly recent kernel) you
> Neil> could
> Neil>   mdadm --grow --bitmap=internal /dev/md0
> 
> Did this.  And now I can do mdadm -X /dev/hde1 to examine the bitmap,
> but I think this totally blows.  To create a bitmap, I add it to an
> md# device, but to examine it, I have to know which sub-devices to
> query?  That's really not what I would expect.

Hmm... I can see that.
-X is a counterpart to -E
They are both letters from EXamine.  They both look at a component and
tell you want is there.
-D (--detail) reports on the array.  Maybe it should be give more
details about any bitmap....
> 
> Neil>   mdadm --grow --bitmap=none /dev/md0
> 
> Neil> and it should work with minimal resync...
> 
> So why would I want to remove the bitmap?

To return you to the state you started in.  You didn't have a bitmap
to start with, so I gave you a recipe that left you with no bitmap.  I
didn't want to assume anything about whether you want a bitmap or not.

Ofcouse, if you want to leave the bitmap there, that is fine.
Possibly even a good idea.

NeilBrown