On Wed, 9 May 2012 21:31:19 +0200 Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx> wrote: > Actually, we solved this issue in a "creative" way. > > Looking at: > > https://raid.wiki.kernel.org/index.php/RAID_superblock_formats > > we identify the proper address and look-up way for the > component order and, using "od -Ax -tx4 /dev/sdXi | less" > we were able to understand the device order. > For the fresh men, please note that address 0xA0 has > the device number and this is a pointer added to 0x100, > where the device role is stored. > While at 0xA0 are stored 4 bytes int, at 0x100 are > stored 2 bytes int (short int), so the "-tx4" of "od" > swaps (due to CPU endianess) each pair of short int, > so the order will be 1 0 3 2 5 4 ... > If "-tx2" is used, than the 0x100 will be correct, > but 0xA0 will have bytes swapped pair wise. Well done!! > > Fortunately, the superblock seemed OK for the data. > Other information, like raid level, was completely > wiped out... > > The only itch left is the data offset. > We plan to try to use mdadm 2.6.7.1 (which originally > created the array) using Ubuntu 10.10 desktop (live). > > Still, I would like to know about backing up the > first few MB of each component with "dd" and about > switching to read only, in order to avoid damage > by LVM/mount. Takes a backup of the first few MB certainly wouldn't hurt, and might help if something goes terribly wrong. (Just as long as you don't restore a backup to the wrong device :-) Yes, starting in --readonly mode, or switching to --readonly mode after you have started the array, is probably a good idea. Some filesystems sometimes try to write even if the device is marked as read-only (e.g. they try to replay the journal). If that happen md will BUG and machine will crash, which might be better than corrupting data. NeilBrown
Attachment:
signature.asc
Description: PGP signature
