Attempt to Read Block From Filesystem Resulted in Short Read

I am struggling with recovering from a hard deejay failure. I shut down my arrangement to avoid a astringent lightning storm in the area. I received no errors on boot but on an attempt to beginning i of my servers from the command line, received a message indicating that the file arrangement was read-just. I checked, and sure enough, the unabridged drive had been mounted read only. I have dealt with this issue before on a different system via fsck, but immediately ran into issues when attempting a fix. Ane particular to annotation is that the drive in question is *non* my chief/boot drive. It is a secondary drive I use for data and backups. My boot bulldoze is non experiencing any issues at all.

Here are a few system details:

Distro: Linux Mint nine RC1 (Isadora), KDE
Patch level: pretty much up to engagement
File arrangement: ext4
Install method: From Live CD using GUI-based install
Using mint4win: no
Division sharing/dual boot: no
RAID: none
Drive blazon: SATA
Device: /dev/sdb (/dev/sda is my primary/boot drive)
System use: webserver, SVN code repository, scratch space
Other info: Since this effect arose, the organization *sometimes* hangs on kick, saying it cannot mount the drive in question. A reboot fixes this issue. When mounted, it always mounts read only.
lspci:

Code: Select all

            00:00.0 Host bridge: Intel Corporation four Series Chipset DRAM Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation iv Serial Chipset PCI Limited Root Port (rev 03) 00:1a.0 USB Controller: Intel Corporation 82801JI (ICH10 Family unit) USB UHCI Controller #iv 00:1a.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #v 00:1a.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #six 00:1a.seven USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family unit) HD Audio Controller 00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port one 00:1c.4 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 5 00:1c.5 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Limited Root Port 6 00:1d.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #ane 00:1d.one USB Controller: Intel Corporation 82801JI (ICH10 Family unit) USB UHCI Controller #2 00:1d.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #three 00:1d.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #one 00:1e.0 PCI span: Intel Corporation 82801 PCI Span (rev 90) 00:1f.0 ISA bridge: Intel Corporation 82801JIB (ICH10) LPC Interface Controller 00:1f.two IDE interface: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller #1 00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller 00:1f.5 IDE interface: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller #2 01:00.0 VGA compatible controller: nVidia Corporation NV45 [GeForce 6800 GTO] (rev a2) 02:00.0 Ethernet controller: Atheros Communications Atheros AR8121/AR8113/AR8114 PCI-Due east Ethernet Controller (rev b0) 03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6101 single-port PATA133 interface (rev b2)          

I checked bulldoze cabling, ability and even swapped the cable to a new port on the controller with no issue. Later on these nuts, I got downward to working on the filesystem itself:

I tried fsck:

Code: Select all

            > fsck.ext4 /dev/sdb e2fsck ane.41.xi (14-Mar-2010) fsck.ext4: Attempt to read block from filesystem resulted in brusk read while trying to open /dev/sdb Could this exist a zilch-length partition          

which is not something I had seen before. Equally this is obviously a common issue, it took some time to find a reasonably coherent discussion of the issues involved via Google: http://www.cyberciti.biz/tips/surviving ... lures.html

Post-obit the instructions at that place:

Code: Select all

            > dumpe2fs /dev/sdb | grep -i superblock                                                                                                                          dumpe2fs 1.41.xi (14-Mar-2010)                                                                                                                                dumpe2fs: Endeavour to read cake from filesystem resulted in short read while trying to open /dev/sdb                                                                                Couldn't notice valid filesystem superblock.          

I so tried:

Code: Select all

            > mke2fs -n /dev/sdb                                                                                                                                              mke2fs ane.41.11 (14-Mar-2010)                                                                                                                                                 /dev/sdb is unabridged device, not but 1 sectionalisation!                                                                                                                        Proceed anyway? (y,n) y                                                                        Filesystem characterization=                                                                Os type: Linux                                                                   Block size=4096 (log=2)                                                          Fragment size=4096 (log=two)                                                       Stride=0 blocks, Stripe width=0 blocks                                           30531584 inodes, 122096646 blocks                                                6104832 blocks (v.00%) reserved for the super user                               First data block=0                                                               Maximum filesystem blocks=0                                                      3727 block groups                                                                32768 blocks per grouping, 32768 fragments per group                                                8192 inodes per group                                                                        Superblock backups stored on blocks:                                                                                                                                       32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,            4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,              102400000          

and subsequently tried a few of the backup superblocks:

Code: Select all

            e2fsck -f -b 32768 /dev/sdb                                                                                                                                     e2fsck ane.41.eleven (14-Mar-2010)                                                           e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdb                                                                                 Could this be a cypher-length sectionalization?          

I repeated the e2fsck for superblock locations: 32768, 98304, and 163840
with the same result. Rather than beating my head against a wall, I did some more
Googling and came across this upshot:

http://www.groupsrv.com/linux/about151483.html

which indicates that the Seagate drive model #ST3600320AS has firmware bug that
make it finiky under linux and may result in situations where the standard recovery
attempts do not work. Sadly, this is the bulldoze model that I own and is currently having issues.

The questions are:
Do I exhaustively go on to attempt superblocks from the list higher up in hopes one works?
Is this really a superblock result or do I have something else weird(er) going on?
Can anyone recall of a style to recover some of the additional missing information on the deejay? I managed to recover my webserver HTML pages and other files via a simple cp command, but my SVN code repository is not recoverable in this manner. While I could try to dd the disk, my main/main bulldoze is not large enough to hold a disk image and I practice non take any other suitable places to dump the epitome to.
Is there whatsoever merit to the merits near Seagate drives made in the link to a higher place?

Thanks!

winklerparepithe.blogspot.com

Source: https://forums.linuxmint.com/viewtopic.php?t=74362