Re: on assembly and recovery of a hardware RAID

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

On Mon, Mar 20 2017, Alfred Matthews wrote:

>>> *** Checking Backup Volume Header:
>>> Unexpected Volume signature '  ' expected 'H+'
>>
>> Here the backup volume header, which is 2 blocks (blocks are 8K) from
>> the end of the device, looks wrong.
>> This probably means the chunk size is wrong.
>> I would suggest trying different chunksizes, starting at 4K and
>> doubling, until this message goes away.
>> That still might not be the correct chunk size, so I would continue up
>> to several megabytes and find all the chunksizes that seem to work.
>> Then look at what else hpfsck says on those.
>
> I'm not actually able to generate happy output in hpfsck using any of
> the following multiples of 4K
>
> 4
> [...]
> 8192
> 16384
> 32768
> 65536
> 131072
> 262144
> 524288
> 1048576
> 2097152
>
> Any chance it's not really an HFS system at all?

Not likely.  hpfsck finds a perfectly valid superblock (or "Volume
Header") at the start of the device.  It just cannot find the end one.

The blocksize is:
     blocksize       : 2000

which is in HEX, so 8K.
The total_blocks is:
     total_blocks    : 732482664

which are 8K blocks, so 5859861312K or 5.4TB (using 1024*1024*1024).
which matches the fact that each partition is 2.73TB.

The problem seems to be that we are not combining the two partitions
together in the correct way to create the original 5.4TB partition.

All we know is that the backup volume header should look
much like the main header, and particularly should have 'H+' in the
signature, which is the first 2 bytes.
i.e. the first two bytes of the volume headers should be
0x4A2B

The second (8K) block of the disk must look like this, and
the second last should as well.
If you can search through both devices for all 8K blocks which
start with 0x4A2B, that might give us a hint what to look for.
I would write a C program to do this.  I might take a while to run, but
you can test on the first device, as you know block 2 matches.


Hmmm... I've got a new theory.  The code is broken.
fscheck_read_wrapper() in libhfsp/src/fscheck.c should set
vol->maxblocks.
It is set to a dummy value of '3' before this is called.
In the "signature == HFS_VOLHEAD_SIG" it sets it properly,
but in the "signature == HFSP_VOLHEAD_SIG" case (which applies to you)
it doesn't.
So it tries to read the backup from block "3-2", or block 1.  And there
is nothing there.

How is your C coding?  You could
  apt-get source hfsplus
and hack the code and try to build it yourself....


NeilBrown



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]