Thanks, I'll take a look. Could use a project, insane as that sounds. On 20 March 2017 at 22:38, NeilBrown <neilb@xxxxxxxx> wrote: > 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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
