Possible to recover from bad fsck?

Question

I had a 3TB WD Red disk with movies and music in my HTPC(with ext4 filesystem). A few days ago the power supply gave up so I took the disk, put it an external USB case in which I usually have a 2TB backup-disk and attached it to my server running Ubuntu 14.04. I was however unable to mount it since the server claimed it had errors. That didn't feel all to strange as the HTPC had been running when the PSU gave up so I fired up a shell with:

sudo fsck -y /dev/sde

It ran for a while and I could mount the drive when it was finished. Now however it only have an empty 2TB partition as opposed to the ~80% full 3TB partition it had before. I'm letting Testdisk analyze it at the moment. But is there some other way to reverse the fsck changes or should I just take it as a lesson and start the lengthy process of adding my media again?

UPDATE: Not sure I get this right, but gdisk seems to think the partition is still using the full disk:

# gdisk -l /dev/sde
GPT fdisk (gdisk) version 0.8.8

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

Found valid GPT with protective MBR; using GPT.
Disk /dev/sde: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): CFAA3FF0-DE38-4FAD-B13B-91811BD71821
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2925 sectors (1.4 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      5860532223   2.7 TiB     0700  primary

But if I mount it, it's only 2TB:

# mount /dev/sde1 /mnt
# df -h /mnt
Filesystem      Size  Used Avail Use% Mounted on
/dev/sde1       2.0T   71M  1.9T   1% /mnt

Not much on it though:

# ls -altR /mnt
/mnt:
total 24
drwxr-xr-x  26 root root  4096 Jul 18 20:54 ..
drwxr-xr-x.  3 root root  4096 Jul  8 12:45 .
drwx------.  2 root root 16384 Jul  8 12:45 lost+found

/mnt/lost+found:
total 20
drwxr-xr-x. 3 root root  4096 Jul  8 12:45 ..
drwx------. 2 root root 16384 Jul  8 12:45 .

Answer 1

External USB enclosures often do one of two things with over-2TiB disks:

• They convert from 512-byte sectors to 4096-byte sectors, thus enabling the disk (up to 16TiB) to be accessed via 32-bit pointers. This works fine so long as the disk is accessed only from the external enclosure. Disks must not be swapped back and forth between such enclosures and direct access via motherboards. Doing so is likely to result in the appearance of partition table damage and can cause filesystem damage.
• They "roll over" access at 2TiB. This results in a disk that appears to be either 2TiB or the remainder of the true size divided by 2TiB -- normally about 700GiB for a 3TiB disk. (Note that TB != TiB; see here for details.) This behavior is a serious problem that effectively prevents use of large disks in enclosures that do this. Putting a disk that had been used internally into such an enclosure usually results in the appearance of a damaged partition table and can result in filesystem corruption if you attempt to use it.

I see no evidence of either of these problems in your gdisk output, but it's not clear if that output comes from the disk connected via the USB drive or in some other way. Also, it's conceivable that the "roll-over" problem might still be occurring, but the enclosure is reporting the disk's true size.

One more point: You say you did sudo fsck -y /dev/sde. That's performing the filesystem check on the whole disk. Most disks are partitioned, though, and the gdisk output indicates your disk is partitioned. Thus, you should have performed the fsck on /dev/sde1, not on /dev/sde. If you reported this accurately, it's conceivable you've actually damaged the filesystem by checking the whole disk rather than the partition. Ordinarily, I'd expect fsck to report an error when you do something like this, but maybe you got unlucky in this.

The bottom line is that you should stop using the disk in an external enclosure, at least unless and until you can verify that your enclosure is not doing any sort of "translation" or "rollover." Instead, access it by plugging it directly into a computer's motherboard. You may still have to repair problems, but at least you won't be creating new ones whenever you write to the disk.