Hard Drive failure in Linux

[Quinton McLeod]

A friend of mine is having issues with his Linux. When attempting to access his HD, he gets these errors:

/dev/hdh1: Invalid argument while reading block 134236528

/dev/hdh1: Invalid argument reading journal superblock

fsck.ext3: Invalid argument while checking ext3 journal for /dev/hdh1


I know nothing about Linux, so I couldn't help him, but hopefully someone here can. What exactly do these errors mean and what should be done to fix them?

Thanks

[Quinton McLeod]

As much as I hate to make multiple posts, I couldn't really edit my last one. My friend has given me more information to hopefully help any of you to solve the problem,

My friend used the command:
fsck -B 8193 /dev/hdh1

I'm guessing this other parameter has something to do with this command too:
/dev/hdh1 is ext3 file system


Because I know little on Linux, I do not know the reason behind entering these commands. Anyway, he's got these errors by entering these commands. I suppose it signifies that his hard drive has issues, but we don't know what it all means or methods to go about correcting the problem.

[kmr]

hi
My name is kmr
I am japanese

Mcleod is pointing out the English method for me. Thank you mcleod


But ext3 filesysem Since trouble management cannot be solved in Japan, I want to borrow the wonderful brains of the direction in the English area.

I have detected abnormalities to the file system.
I at once the server and rose so that /dev/hdh1 might not be mounted.
I struck the fsck/dev/hdh1 command.
But I got this error message

/dev/hdh1: Invalid argument while reading block 134236528
/dev/hdh1: Invalid argument reading journal superblock
fsck.ext2: Invalid argument while checking ext3 journal for /dev/hdh1

I struck dumpe2fs /dev/hdh1 command

I was able to extract the information on a super block in /dev/hdh1, and the information on block size and a backup super block.

Try
I struck -b 8193 /dev/hdh1
But I got errer message

"he superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device>"

I did search superblocks about

ext2fs_read_bb_inode: Illegal triply indirect block found
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: f130259a-feba-453d-b9f6-1138089148df
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype sparse_super
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 9781248
Block count: 19537678
Reserved block count: 976883
Free blocks: 4451451
Free inodes: 9780761
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Last mount time: Sat Dec 14 08:04:18 2002
Last write time: Sun Dec 15 14:35:10 2002
Mount count: 4
Maximum mount count: -1
Last checked: Wed Dec 11 21:52:59 2002
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal UUID: <none>
Journal inode:
Journal device: 0x0000
First orphan inode: 0

Group 0: (Blocks 0-32767)
Primary Superblock at 0, Group Descriptors at 1-5
Block bitmap at 6 (+6), Inode bitmap at 7 (+7)
Inode table at 8-519 (+
0 free blocks, 16372 free inodes, 3 directories
Free blocks:
Free inodes: 13-16384
Group 1: (Blocks 32768-65535)
Backup Superblock at 32768, Group Descriptors at 32769-32773
Block bitmap at 32774 (+6), Inode bitmap at 32775 (+7)
Inode table at 32776-33287 (+
0 free blocks, 16384 free inodes, 0 directories
Free blocks:
Free inodes: 16385-32768
Group 2: (Blocks 65536-98303)
Block bitmap at 65536 (+0), Inode bitmap at 65537 (+1)
Inode table at 65544-66055 (+
0 free blocks, 15998 free inodes, 1 directories
Free blocks:
Free inodes: 33155-49152
Group 3: (Blocks 98304-131071)
Backup Superblock at 98304, Group Descriptors at 98305-98309
Block bitmap at 98310 (+6), Inode bitmap at 98311 (+7)
Inode table at 98312-98823 (+
0 free blocks, 16384 free inodes, 0 directories
Free blocks:
Free inodes: 49153-65536
Group 4: (Blocks 131072-163839)
Block bitmap at 131072 (+0), Inode bitmap at 131073 (+1)
Inode table at 131080-131591 (+
0 free blocks, 16384 free inodes, 0 directories

I did think backsuperblocks is 8193*4094-4096=33554432
I try
fsck -b 33554432 /dev/hdh1
But The same error

Would you teach the hard disk restoration method?

[Dolda2000]

/dev/hdh?! Are you serious? Do you have eight IDE drives? That's not bad...
Anyway, it would seem that you have damaged blocks on your drive. Try running "badblocks /dev/hdh1". You don't have to run through it all, just see if every block appears damaged or just some of them.
Have this drive worked before, and, if so, for how long?
Also, are there several partitions on the disk? In that case, try checking the other ones as well, to see if the problem is all over the drive or not.
I'm also thinking that it might be the IDE controller that's been damaged somehow. Would it be possible for you to try installing that disk to the first IDE controller in your system (so that the drive becomes hda, hdb, hdc or hdd) and see if that works?
If it is the disk itself that's physically damaged, there's not much to do. One could try to extract the little data that might be available, but I wouldn't hope for too much. The only way to repair such a disk is to send it to one of those companies that repairs hard disks, but that usually costs at least $5000 or so.

[kmr]

I have already tried badblocks. However, the result was 0. Therefore, I think that there cannot be no physical damage on a hard disk. However, I think that that it can consider has a super block and an amusing journal system. In this case, it also knows that it can restore by 'fsck-b blocks/dev/hdh1' etc. However, since even it is not made, I am in trouble very much. Thank you, I appreciate advice of Dolda2000 and you.

[Dolda2000]

I noticed that the "journal inode" entry in the output from dumpe2fs was empty. That should not be so. It's just a number, so it should at least say something. Can you double check on that?
Also, can you run fsck again and check /var/log/messages if it logs any kernel messages during fsck? They might be able to tell something in that case.

[wassy121]

also, maybe it was set up as an ext2 partition, not ext3. If the journal inode is null you can always just redo the journal (some mke2fs command I think. Man pages are your friends)

[Dolda2000]

But still, "Filesystem features" includes has_journal, so it must at least have had a journal. Plus, journal inode should still display as 0, right? Of course, without has_journal, it wouldn't display at all, but now has_journal is there, so it does, and I don't think that it should be just empty.