Mark Cullen writes:
> Greg Oster wrote:
> > Mark Cullen writes:
[snip]
> > 
> > 
> > If the array won't be used again, then just make sure you do a 
> > 'raidctl -A no raid0' so that the components don't get auto-configured.
> > You can then do a 'raidctl -u raid0' to unconfigure.  If you want to 
> > nuke the labels (something that raidctl doesn't have an option for)
> > you can use something like:  
> > 
> >  dd if=/dev/zero of=/dev/wd1a bs=512 count=1 seek=32
> 
> You mean, if I just do a `raidctl -u raid0`, if I were to reboot the 
> array would infact reappear and 'auto-configure' itself?

If you had done a 'raidctl -A yes raid0', then "yes".  Doing an 
unconfigure doesn't change the autoconfigure status.

> Under what situation(s) might I want to nuke the labels? A little 
> confused there :)

E.g. if you planned to move the disk to a different machine, and add 
it to a different array...  
 
> >>Suprisingly, even though the data on these two disks now differs, the 
> >>status of the array is ok on both disks. I assume this is because I 
> >>forced a reconfiguration, and there's really no easy way to tell that 
> >>the data differs.
> > 
> > 
> > Yes...  "-C" is to be used for new arrays with nothing on them, or
> > when you want to say "I know better, trust me"...  
> 
> So, this would indeed be the correct way of taking a disk (not a spare) 
> out of the array configuration, as I have in the examples?

Using '-c' would be better, as that would at least make sure that the 
remaining components are at least consistent with each other.  ('-C' 
overrides any consistency checks..)

> > 
> > 
> >>A `raidctl -i raid0` succeeds (admittedly I have no 
> >>idea what it does, however),
> > 
> > 
> > For a RAID 1 configuration, it will verify the that the data bits 
> > are in sync... 
> 
> Now this is interesting... see below
> 
> > 
> > 
> >>but the data on the two disks is still 
> >>different, that is, /dev/wd3a still has the old copy of the data. 
> > 
> > 
> > Um... after the 'raidctl -i raid0' completes, the data parts of wd1a 
> > and wd3a had better be *exactly* the same!
> 
> They weren't the same afterwards! If I mounted just the disk that was 
> missing when I added the new data, after doing an -i, the data was *not* 
> there on that disk. I had to force a rebuild of the disk in order to get 
> the data on to it.
>
> However, I may know why? I took wd1 out, and put the new data on wd3. If 
> I issue a -i, does it use the first disk in the array config to rebuild 
> the parity? 

Yes.  The first disk in a RAID 1 set is considered the 'master', and 
in the face of having 2 disks where it can't tell which is "more 
correct", the 'master' will be used as the difinitive source.

> This would have meant the old copy of data on wd1 would have 
> been used?!

Yes.  So what you would have seen on wd3 should have been the old 
data. (and the new data that was on wd3 would be gone).

The data bits *have* to be the same after a '-i'.  If they arn't then 
I've got a pretty serious bug to fix...

> > 
> > 
> >>In 
> >>such a situation then, am I to force the re-added disk to "failed" and 
> >>rebuild it?
> > 
> > 
> > Yes.  With raid0 in operation with just wd1a, you could have done:
> > 
> >  raidctl -a /dev/wd3a raid0
> >  raidctl -vF absent raid0
> > 
> > and watched it rebuild :)
> 
> Ah! Would that have put /dev/wd3a in to the 'absent' slot, and removed 
> it from the 'spares'? If so, that's quite neat!!

It's not *quite* that automated yet, but with a quick reboot it would 
automatically move to the right spot... 

> Thanks for your reply Greg :)

No problem :)

Later...

Greg Oster