Short read while trying to open partition

Question

On my personal home computer running Kubuntu Linux 13.04 I'm having trouble mounting a partition that is very dear to me. My backup policy is to perform a backup about monthly, so I do have a backup from August :). Is there any way to recover the personal files that are on this drive?

The drive is a 1.5 year old 1000 GiB Western Digital Green drive, with home mounted on /dev/sdc2, the filesystem root on /dev/sdc6, and media files on /dev/sdc3. Therefore of course sdc2 would be the one to go! So far as I know there were no power outages or other such events during the life of the drive. I managed to get this information by running a Kubuntu LiveCD:

kubuntu@kubuntu:~$ sudo fdisk -l

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes                                                                                                                                                                                                       Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00008044

  Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        4094    88066047    44030977    5  Extended
/dev/sdc2        88066048  1419266047   665600000   83  Linux
/dev/sdc3      1419266048  1953523711   267128832   83  Linux
/dev/sdc5            4096     6146047     3070976   82  Linux swap / Solaris
/dev/sdc6         6148096    47106047    20478976   83  Linux
/dev/sdc7        47108096    88066047    20478976   83  Linux


kubuntu@kubuntu:~$ sudo mount -t ext4 /dev/sdc2 c1
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
  missing codepage or helper program, or other error
  In some cases useful info is found in syslog - try
  dmesg | tail  or so


  kubuntu@kubuntu:~$ sudo debugfs -c /dev/sdc2 
debugfs 1.42.5 (29-Jul-2012)

/dev/sdc2: Attempt to read block from filesystem resulted in short read while opening filesystem
debugfs:  quit


kubuntu@kubuntu:~$ sudo fsck /dev/sdc2
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc2
Could this be a zero-length partition?


kubuntu@kubuntu:~$ sudo fsck.ext4 -v /dev/sdc2
e2fsck 1.42.5 (29-Jul-2012)
    fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc2
Could this be a zero-length partition?


kubuntu@kubuntu:~$ dmesg | tail
[ 2684.532855] Descriptor sense data with sense descriptors (in hex):
[ 2684.532858]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 2684.532876]         05 3f c8 b0 
[ 2684.532885] sd 5:0:0:0: [sdc]  
[ 2684.532893] Add. Sense: Unrecovered read error - auto reallocate failed
[ 2684.532898] sd 5:0:0:0: [sdc] CDB: 
[ 2684.532902] Read(10): 28 00 05 3f c8 b0 00 00 08 00
[ 2684.532917] end_request: I/O error, dev sdc, sector 88066224
[ 2684.532927] Buffer I/O error on device sdc2, logical block 22
[ 2684.532973] ata6: EH complete

Help me Unix & Linux, you're our only hope.

Answer 1

(I know this is an old question, I came across this problem myself and got my FS back to life without ddrescue, so I'll share the expericence for anyone else encountering this)

Ext filesystems store backups of the superblock -- for an occasion just like this one.

First, determine the locations of the backups (make sure you have the -n option! otherwise this will wipe the file system with a new one):

mke2fs -n /dev/sdxx

This is a test run (i.e. no write) of FS creation routine. It will let you know the offsets of where it would put superblock backups if it were creating a filesystem. If you know your FS block size to be something other than 4096, you must also specify the parameter -b {blocksize} to get the right numbers.

For 4096-sized blocks, first backup superblock will be at 32768. If the following operations fail with the same error message about bad superblock/short read, try the next superblock backup from the list mke2fs gave you.

Next, you can either mount the filesystem using the backup superblock like this

mount -o sb=32768 /dev/sdxx /mnt/sdxx

then explore the FS from your file manager, copy undamaged files etc.

Or, to actually fix the FS, you can run fsck with backup superblock like this

e2fsck -fy -b 32768 /dev/sdxx

Here -f makes it scan the disk even if it's not dirty and -y answers yes to all enquiries about fixing stuff. The -b option, aside from specifying the backup superblock, will make it update the original superblock with info from backup.

After this, you should have your filesystem back.

If e2fsck fails to write the main superblock If the superblock got corrupted because it's on a bad sector e2fsck will finish the run, attempt to update the superblock, and give you the following error message:

Error writing block 1 (Attempt to write block from filesystem resulted in short write)

Obviously, the main superblock isn't updated and the whole e2fsck run is in vain.

You need to hint the disk to remap that sector -- by writing zeroes to it. Thanks to @Keith for pointing this out: the next command can make a lot of mess if mistyped, so triple-check it before running. Here's the magic:

dd if=/dev/zero of=/dev/sdxx bs=4096 count=1 seek=0

This will write 1 4096-sized block of zeroes to sdxx at offset 0. Don't forget to account for different block size if that's the case for you.

After that you'll be able to write to superblock (which will be on a different physical sector transparently to you). Now, you run the e2fsck command above again and it should succeed writing the superblock allowing you to mount the FS normally.

Goes without saying Now you should backup the critical data to another physical drive and, if you still plan on using the filesystem, run

e2fsck -fccy /dev/sdxx

PS Kudos to @Nemo on this find: in case all of the backups of the superblock of your FS are corrupted, mke2fs/mkfs has the -S option that will re-create the superblock and group descriptors as if creating a new filesystem, without touching anything else. But you absolutely have to be sure your blocksize is right and the man page says you should run e2fsck after it and there are no guarantees about data being left for rescuing. Read the man page and throw a plus on this answer.

Answer 2

There might still be hope, but your drive seems to have hardware problems (my interpretation of the read error in dmesg output).

You should try to make a copy of what is recoverable from that partition onto another drive (to minimize disc access). Use ddrescue for that, it might take a while but gets most if not all of the recoverable data of the partition.

If possible start from another disc, from a Live CD, or connect the drive to a different computer that has its own Linux to boot from. The reason I would do so is that the read errors while doing ddrescue probably has an impact on the disc access speed on the other partitions.

Once you have that copy, lets call that the original copy, as file on another disc, make a copy of that copy. Then try to do a filesystem check on that copy. If that recovery scrambles the copy, you can start from the original copy and try once more, something else.