On 2018/10/7 下午4:09, evan d wrote: >> If first 128M doesn't hit, I highly doubt something more strange happened. > > Not sure I follow, do you mean if it doesn't hit then it's likely > something else went wrong?
Yes. If it's just a simple offset, it should hit. If it's some simple corruption like bit rot, it shouldn't cause all super blocks to be corrupted so seriously. > > >> I'm considering something like encryption. >> Maybe the disk is already encrypted by hardware? > > The drives were never encrypted, none of my drives are > > >> Windows is just a black box, I have no idea what a Windows could do to a >> disk. >> >> But it doesn't explain why the 2nd super block can't be located, unless >> Windows is wipe more data than the first 128M. > > I'm thinking Windows may have tried to convert them to Dynamic disk on > detecting them and assuming they're empty. If that's the case, and sharing with Windows can't be avoided, then next time please use partition table (GPT/MBR) other than raw disks. > >> >> If the disk is larger than 256G, would you please try to locate the last >> possible super at 256G? > > They're both 6TB drives > >> >> # dd if=/dev/sdb bs=1M of=last_chance.raw count=128 skip=256M >> # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" last_chance.raw > > dd returns: > dd: /dev/sdb: cannot skip: Invalid argument My fault, skip should be 256K not 256M. Thanks, Qu >
signature.asc
Description: OpenPGP digital signature
