2

I have a 4TB WD hdd (with sector size of 512e/4096) that was first formatted as GPT/ext4 with an usb-sata enclosure/adapter on a Raspberry Pi 3. Apparently the load was too much for Rpi3, and inconsistency on usb port voltage eventually fried the enclosure. This enclosure controller was one of those which "translated" sector size of larger disk to 4096 for the OS, while the disk itself had the emulated 512e sector size to the enclosure. So trying to access it without that enclosure won't find the partition correctly.

I can access the data with Testdisk setting the correct sector size of 4096, but before taking steps to write a new partition table I decided to check the disk again with a new enclosure of the exact model used to create de filesystem in the first place. Apparently the voltage fluctuation or the sudden powering off of the enclosure caused a corruption to the disk filesystem. I'm not sure what should I conclude from the information gathered so far and what steps should I take to restore the filesystem without losing data. Here is what I tested:

Testdisk with corrected geometry of sector size set to 4096 and partition table of GPT finds the partition like this:

Disk /dev/sdc - 4000 GB / 3726 GiB - CHS 476930 64 32
     Partition               Start        End    Size in sectors
   P Linux filesys. data          256  976754638  976754383

Using the enclosure with sector translation, fdisk -l display the incorrect and unreadable partition table as this:

GPT PMBR size mismatch (976754643 != 976754378) will be corrected by write.
Disk /dev/sdc: 3,64 TiB, 4000785936384 bytes, 976754379 sectors
Disk model: Storage Device  
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdc1           1 976754378 976754378  3,6T ee GPT

dumpe2fs confirm the problem with wrong detection:

dumpe2fs: Bad magic number in super-block while trying to open /dev/sdc
Couldn't find valid filesystem superblock.
/dev/sdc contains `DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 976754643 sectors, extended partition table (last)' data

Also hdparm -N /dev/sdc reports HPA error

/dev/sdc:  max sectors   = 7814035055/1(7814037168?), HPA setting seems invalid (buggy kernel device driver?)

By running gdisk I get the following information:

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

So I checked SMART information for the disk. First thing I noticed was this error issued on dmesg:

23:51:48 2023] sd 3:0:0:0: [sdc] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
23:53:49 2023] Buffer I/O error on dev sdc, logical block 0, async page read
23:53:49 2023] sd 3:0:0:0: [sdc] tag#21 device offline or changed
23:53:49 2023] I/O error, dev sdc, sector 1 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2

It repeats for logical blocks 0 to 7 and sectors 0 to 7, only once during the entire test. Otherwise, the test itself reports the disk is ok:

SMART Status not supported: Incomplete response, ATA output registers missing
SMART overall-health self-assessment test result: PASSED
...
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   171   167   021    Pre-fail  Always       -       6441
  4 Start_Stop_Count        0x0032   093   093   000    Old_age   Always       -       7730
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       7018
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       54
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       39
193 Load_Cycle_Count        0x0032   193   193   000    Old_age   Always       -       21893
194 Temperature_Celsius     0x0022   117   109   000    Old_age   Always       -       33
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing

I've tried to fix the superblock error by copying with fsck -b and fsck.ext4 -p -b 32768 -B 4096 /dev/sdc the available superblocks backups (found with mke2fs -n) but all of them failed because couldn't be read as ext4 valid information:

/sbin/e2fsck: Bad magic number in super-block while trying to open /dev/sdc

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:...

Back to gdisk I tried verification and got this results:

Command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 976754379 sectors, needs to be 976754644 sectors.)
The 'e' option on the experts' menu may fix this problem.

Warning: There is a gap between the main partition table (ending sector 5)
and the first usable sector (256). This is helpful in some exotic configurations,
but is unusual. The util-linux fdisk program often creates disks like this.
Using 'j' on the experts' menu can adjust this gap.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 976754638, but backup header is at
976754643 and disk size is 976754379 sectors.
The 'e' option on the experts' menu will probably fix this problem

Problem: partition 1 is too big for the disk.

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

Caution: Partition 1 doesn't end on a 256-sector boundary. This may
result in problems with some disk encryption tools.

Identified 6 problems!

Tried the expert e option, and verified again with v:

Expert command (? for help): e
Relocating backup data structures to the end of the disk

Expert command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Warning: There is a gap between the main partition table (ending sector 5)
and the first usable sector (256). This is helpful in some exotic configurations,
but is unusual. The util-linux fdisk program often creates disks like this.
Using 'j' on the experts' menu can adjust this gap.

Problem: partition 1 is too big for the disk.

Warning! Secondary partition table overlaps the last partition by
515 blocks!
You will need to delete this partition or resize it in another utility.

Caution: Partition 1 doesn't end on a 256-sector boundary. This may
result in problems with some disk encryption tools.

Identified 3 problems!

I didn't wrote the changes to the disk because it seemed it could introduce further problems as shown in the second verification and I have no spare disk to backup 4TB, so my only hope is fixing the filesystem without formatting.

So, what do you think is happening here? Any ideas on how to fix this? Thanks!

Edit:

I just noticed that the logical block/sector error in the dmesg may be related to a dock hub I was using to run SMARTctl. Keeping the hub on without any disk attached produced similar messages, so maybe that was the case. Nonetheless, it still not clear to me the condition of the disk because of the errors with HPA corruption and gdisk information. How to fix that without damaging to an unrecoverable point the data in the disk?

Edit 1

Apparently some models of usb enclosure "hijacks" part of the ending bytes from the disk for their own operations. Removing the disk from the enclosure shows this "hidden" bytes to the OS again. My guess is that, specially in GPT case, it will look like the partition table is now wrong, poorly sized or corrupted. Info from here: https://www.reddit.com/r/DataHoarder/comments/ejqdeh/psa_do_not_swap_your_nonempty_drives_into/

6
  • can you browse partition and see the files in testdisk?
    – Hydranix
    Commented Apr 21, 2023 at 12:58
  • Yes, by changing the sector size on geometry menu, the files are accessible. The problem is what will happen if i save this partition that a) was created with an emulated sector size by the usb enclosure and b) with an underlying problem on the disk that it still not clear to me
    – autogris
    Commented Apr 21, 2023 at 17:57
  • If you can browse the files from twstdiskm back them up from there. Saving the partition if the files are browseable should be ok, but backup important files to be safe.
    – Hydranix
    Commented May 5, 2023 at 16:43
  • As stated in the question, I don't have 4TB spare disk to backup, so I'm looking for commentaries that help me to understand the real situation of the disk and how to properly repair it without formating....
    – autogris
    Commented May 7, 2023 at 2:21
  • Are you able to access the disk through a losetup -P -b 4096 /dev/sdc /dev/loop0? I/O errors reported by the disk are not a good sign (as those would not come from this issue). Commented May 7, 2023 at 6:05

0

You must log in to answer this question.