Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm unable to mount my 300GB external (in external enclosure) HDD's single partition. None of the fsck tools add anything, they cannot even recognize the partition. I had forgotten whether I had used ext4 or reiserfs myself. The HDD seems ok. Testdisk saw a linux partition but didn't give any more details.

Until ... I followed Recovering ext4 superblocks and tried the sudo losetup -v -o $i /dev/loop1 /dev/sdc command. Now testdisk at least gives me a green label, tells me it's a reiserfs 3.6 partition and gets the correct device label! I especially had luck with i=32768:

$ dmesg
[10147.132161] REISERFS (device loop1): found reiserfs format "3.6" with standard journal
[10147.132204] REISERFS (device loop1): using ordered data mode
[10147.132206] reiserfs: using flush barriers
[10147.132335] REISERFS (device loop1): journal params: device loop1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[10147.132745] REISERFS (device loop1): checking transaction log (loop1)
[10147.133630] REISERFS warning: reiserfs-5090 is_tree_node: node level 61404 does not match to the expected one 4
[10147.133638] REISERFS error (device loop1): vs-5150 search_by_key: invalid format found in block 67403788. Fsck?
[10147.133644] REISERFS (device loop1): Remounting filesystem read-only
[10147.133652] REISERFS error (device loop1): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [1 2 0x0 SD]
[10147.133660] REISERFS (device loop1): Using r5 hash to sort names

I can't mount it as you see but to me it seems I'm getting close:

$ sudo mount -t reiserfs /dev/loop1 /mnt
mount: /dev/loop1: can't read superblock

Am I seeing ghosts just because I skip some bytes? Why doesn't testdisk see this from the raw /dev/sdc1? I mostly used readonly tools but I might have asked testdisk to write once (to the partition table?) so I could have lost parts, though I don't doubt most can be recovered. And most of all, how do I continue from here?

I could run reiserfsck on the raw /dev/sdc1, but if there's a reason why the offset works better, how do I consolidate it onto my HDD first?

Please indicate the implications of your solution appropriately (how clean? if it writes I want to know). I am ok with giving up the data on the disk (nothing personal), but if it's easy to fix I'd like that. Also, Foremost seems to be able to recover my files, but I have no space to write them to.

UPDATE1: Weird that I' m seeing less results on my actual laptop rather than on the Ubuntu LiveCD (perhaps this is the cause of my troubles). I tried some stuff and I only get some smartness from reiserfsck if I use the losetup from above and then run reiserfsck --check /dev/loop1. However it aborted replaying transactions it seems. I get:

[  682.743728] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[  682.743734] ata1.00: ST-ATA: DRQ=0 without device error, dev_stat 0x50
[  682.743740] ata1.00: failed command: DEVICE CONFIGURATION OVERLAY
[  682.743747] ata1.00: cmd b1/c2:00:00:00:00/00:00:00:00:00/40 tag 0 pio 512 in
[  682.743749]          res 50/00:00:00:00:00/00:00:00:00:00/40 Emask 0x202 (HSM violation)
[  682.743753] ata1.00: status: { DRDY }
[  682.743763] ata1.00: hard resetting link
[  683.060965] ata1.01: hard resetting link
[  684.087234] ata1.01: failed to resume link (SControl 0)
[  684.243064] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  684.243086] ata1.01: SATA link down (SStatus 0 SControl 0)
[  684.283150] ata1.00: configured for UDMA/133
[  684.283860] ata1: EH complete
[  727.846495] usb 2-1.3.1: reset high-speed USB device number 6 using ehci_hcd
[  766.757684] usb 2-1.3.1: reset high-speed USB device number 6 using ehci_hcd

Is this a drive failure? Doesn't look like it.

UPDATE2: It had to recreate the journal header, then had to recreate the superblock, and it is now rebuilding the tree (but at least it is doing something). From my experience that means I won't get to my data in a coherent fashion :-). But it is all doing this in the loop device. This brings me back to my initial question: How will I ever get back from a working partition in a loop device to a directly accessible working partition (63 cylinders off I suppose)?

UPDATE3: I rebuilt the tree and got a lost+found with some stuff back. When trying to mount it the next day, it again could not be mounted. Overall it showed random behavior. I think the hard disk actually has died. SMART data was the first thing I tried but it could never be accessed, I - wrongly? - assumed this was because of the enclosure. I tried to format it with a new partition but even that wouldn't stick very long beyond the formatting.

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

Recovering a damaged reiserfs partition can sometimes destroy the data you're trying to recover (I know, I've done it).

So, first off, take a drive level image of the whole disk to something else.

dd if=/dev/source of=/home/diskimage.img

After you've got the disk image taken, then, and only then, try an fsck or other recovery.

There are several links that can help with trying to recover reiserfs. I'll give you a couple.

Hope those help. A lot of links for "recover reiserfs" or "reiserfs partition lost" and up being links to commercial recovery services, which I figured you weren't looking for...

share|improve this answer
    
Yeah, I've been through it myself a few times over the last decade. But what with the offset? Should I just go and do a --rebuild-sb and --rebuild-tree without setting that straight? Or does it have no meaning? (Again, can't take an image and rather lose my data then.) –  pjv Jun 10 '12 at 16:55
    
After imaging the drive, I'd try the default methods, including some of the tricks in the links (rewriting the drive from the image if anything gets too damaged in an attempt), and then get more creative if necessary until you get a result. It could be that one of the superblocks got damaged, and that is why some things detect properly and others don't. I'd say do a little trial and error (restoring from the image if anything appears to do catastrophic damage, and go again) –  killermist Jun 10 '12 at 17:03
    
If an offset seems "more right", maybe try that first. –  killermist Jun 10 '12 at 17:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.