AW: two-disk-failure question

AW: two-disk-failure question

[Martin Bene]

> "To get this to work, you'll need to have an up to date /etc/raidtab - if
it 
> doesn't EXACTLY match devices and ordering of the original disks this will 
> not work as expected, but will most likely completely obliterate whatever 
> data you used to have on your disks."

While the procedure you're refering to will still work, it's been made pretty
much obsolete by the new mdadm tool.

> Now I can't be completely absolutely sure I did not -at some point-
re-order 
> cables and such. So my obvious question is:  Is this step (mkraid --force 
> with one of the offline disks defined as failed-disk) destructive, or could
I 
> (theoretically) experiment endlessly with the order in which the disks are 
> defined in /etc/raidtab before I decide to mount it read-write and
raidhotadd 
> a fresh disk ?

Urr, hard question there: IF 
	- you've marked a disk as failed AND
	- there's no spare disks in your configuration THEN
yes, the mkraid -force is non - destructive. it'll only touch the raid
superblocks and nothing else. 

Be careful when checking the results of the operation though: even mounting a
filesystem readonly can result in write access to the device when using a
journaling filesystem (ext3). Prior to mounting, it'll try to play back the
jounal..

> Second question, If one is sufficiently adept at looking at raw disk 
> structures (notably the suberblocks), can a human find out which disk is 
> which, ie. in which order they DO belong ?

Yes :-)

OK, that wasn't really helpful. What you really want to do is grab a copy of
mdadm. It's got support for resolving just the problem you're experiencing:
it can override the event counter when assembling an array but still use the
rest of the raid superblock. In adition it can parse the information in the
superblock and show you exactly what's in each of your superblocks.

Bye, Martin

Re: AW: two-disk-failure question

[maarten van den Berg]

On Saturday 18 October 2003 09:46, Martin Bene wrote:

> While the procedure you're refering to will still work, it's been made
> pretty much obsolete by the new mdadm tool.

Thanks.  I installed that.  I examined the disks and they seem to be in the 
same order as raidtab says.  From /var/log/messages I gather that the first 
disk that failed was /dev/hdf1. This is consistent with mdadm --examine, I 
think, since the superblock on disk hdf says all six are active, the 
superblock on hde says hdf is faulty, and the four other disks say both hde 
and hdf are faulty.

      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      33       65        1      faulty   /dev/hdf1
   2     2      34        1        2      active sync   /dev/hdg1
   3     3      34       65        3      active sync   /dev/hdh1
   4     4      56        1        4      active sync   /dev/hdi1
   5     5      57        1        5      active sync   /dev/hdk1

So after some reading and with hands shaking I did assemble it back by using 
mdadm leaving /dev/hdf1 out.

> Be careful when checking the results of the operation though: even mounting
> a filesystem readonly can result in write access to the device when using a
> journaling filesystem (ext3). Prior to mounting, it'll try to play back the
> jounal..

Thanks much for the warning !  This is indeed reiserfs, so I tried to find the 
least harmful way to check the array before mounting, which (I do hope) seems 
to be reiserfsck --check.  It is (still) running as I write this but I have 
good hopes since a botched array would probably not even resemble a reiserfs, 
much less report no fatal errors early in the check process.

> OK, that wasn't really helpful. What you really want to do is grab a copy
> of mdadm. It's got support for resolving just the problem you're
> experiencing: it can override the event counter when assembling an array
> but still use the rest of the raid superblock. In adition it can parse the
> information in the superblock and show you exactly what's in each of your
> superblocks.

Yes.  Thanks.  What does that "event counter" number mean ? (Events : 0.10)

> Bye, Martin

Maarten

-- 
Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER