Le Fri, 23 Feb 2018 00:42:11 +0100
Alatun Rom <alatun.rom@xxxxxxxxx> écrivait:
> As far as I understood, xfs_repair considers the file system
> unfixable, because the secondary superblocks are not found at the
> offsets, where they should be.
I don't think so, as it reports "invalid superblock signature", this is
most probably the culprit. It needs at least one proper, uncorrupted
superblock.
> The blocks found look quite ok.
> My guess: because the VMDK container got damaged, the information of
> the internal partitions is now incorrect, so testdisk did extract a
> file that is somehow broken. But from what I've seen so far, it could
> be possible to fix it up to the point, to extract some files.
>
I never knew that testdisk could be used like that. Is the volume of
the right size, matching the original partition?
> What is unclear for me: why are 7 SSB found? Is this a geometry issue?
The adresses are super weird: the 4 first seem OK, the the last three
are bizarrely close to each other:
32204029952
57813565440
64185663488
96412992512
96413164544
96413271040
96419537920
> The found superblocks tell, that a total of 4 superblocks should
> exist. What happens if you grow an XFS file system? Do additional
> stripes generate a layout like this? Is the distance between the
> superblock copies ALWAYS a constant value? In my scenario the distance
> of the first 3 superblocks is not a fixed value. But how can blocks
> get lost? I don't think this is possible with VMDK to "mark blocks as
> deleted" inside a partition and they are skipped when reading a
> partition.
Honestly, AFAIK VMDK are hollow files. If it gets damaged all bets are
off...
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@xxxxxxxxxxxxxx>
| +33 1 78 94 84 02
------------------------------------------------------------------------
Attachment:
pgpO1ankNdS14.pgp
Description: Signature digitale OpenPGP
