Hi there !

Could anyone give me a diagnosis on my hard disk problem ?

On an old Fujitsu, I had installed RedHat 6.0, a few years ago. It worked
for years
without any problem. Then, last june, I had a crash on a
partition, and I had to re-install, which I did only last week. At first,
everything seemed OK, but, after 2-3 days and about 3 ou 4 shutdown and
startup, I ran into a problem similar to that of last june, except that
it occured in /dev/hda5 instead of /dev/hdc3 last time :

'/dev/hda5 contains a filesystem with errors ! check forced...

.... kernel panic, [file system] inconsistency... run fsck manually...'

at this point, I typed the root pasword as required, got dropped to a
shell, and typed:

'fsck /dev/hda5' :

'PASS 1 : Checking inodes, blocks and sizes... Duplicate blocks found
...... Invoking duplicate block passes... etc...

PASS 1B : Rescan for duplicate bad blocks... Duplicate bad blocks in
inode 55299 : 221452
55300 : 221453
55301 : 221454
.... etc...

PASS 1C : Scan directories for inodes with dup blocks
...............
PASS 1D : Reconciling duplicate bad blocks

file ... (inode 55305, mod time Sat Aug26,2006 has 3 duplicate blocks
shared with 3 files.....

etc.., etc..,
/etc/mail...

Clone Duplicate bad blocks => Y

Pass 2 : checking directory structure : the '..' in /etc/mail (55299) is
missing... FIX => Y

PASS 4 : checking reference counts: inode 2 reference count is 15, should
be 16 FIX => Y, inode 18433 reference count is 27, should be 26 FIX =>
Y... etc... unattached inode 55301

etc...

PASS 5 : checking group summary information. Block bitmap differences
+221461 +221462 .... 221486... etc...

etc... etc... it took at least 15 minutes to fix everything, replying 'Y'
to every ask. Then I got :

'/dev/hda5 : filesystem was modified. /dev/hda5 6703/110592 files (0.4%
non contiguous.

on reboot, I had:

/dev/hda5 clean
/dev/hdc2 clean
/dev/hdc3 clean

After so many fixings, I rather expected that it would not reboot
properly, but, so far, I have not found anything wrong in the repaired
system.

Last june, about the same thing had happened, not on /dev/hda5, but on
/dev/hdc3. There were so much fixing to be done, that I had given up. This
time, it happens on a newly re-installed system.

I suppose that a similar problem is going to happen again some time
sooner or later...

Thanks in advance for any useful input

Bernard wrote:
> Hi there !
>
> Could anyone give me a diagnosis on my hard disk problem ?
>
> On an old Fujitsu, I had installed RedHat 6.0, a few years ago. It worked
> for years
> without any problem. Then, last june, I had a crash on a
> partition, and I had to re-install, which I did only last week. At first,
> everything seemed OK, but, after 2-3 days and about 3 ou 4 shutdown and
> startup, I ran into a problem similar to that of last june, except that
> it occured in /dev/hda5 instead of /dev/hdc3 last time :
>
> '/dev/hda5 contains a filesystem with errors ! check forced...
>
> ... kernel panic, [file system] inconsistency... run fsck manually...'
>
> at this point, I typed the root pasword as required, got dropped to a
> shell, and typed:
>
> 'fsck /dev/hda5' :
>
> 'PASS 1 : Checking inodes, blocks and sizes... Duplicate blocks found
> ..... Invoking duplicate block passes... etc...
>
> PASS 1B : Rescan for duplicate bad blocks... Duplicate bad blocks in
> inode 55299 : 221452
> 55300 : 221453
> 55301 : 221454
> ... etc...
>
> PASS 1C : Scan directories for inodes with dup blocks
> ..............
> PASS 1D : Reconciling duplicate bad blocks
>
> file ... (inode 55305, mod time Sat Aug26,2006 has 3 duplicate blocks
> shared with 3 files.....
>
> etc.., etc..,
> /etc/mail...
>
> Clone Duplicate bad blocks => Y
>
> Pass 2 : checking directory structure : the '..' in /etc/mail (55299) is
> missing... FIX => Y
>
> PASS 4 : checking reference counts: inode 2 reference count is 15, should
> be 16 FIX => Y, inode 18433 reference count is 27, should be 26 FIX =>
> Y... etc... unattached inode 55301
>
> etc...
>
> PASS 5 : checking group summary information. Block bitmap differences
> +221461 +221462 .... 221486... etc...
>
> etc... etc... it took at least 15 minutes to fix everything, replying 'Y'
> to every ask. Then I got :
>
> '/dev/hda5 : filesystem was modified. /dev/hda5 6703/110592 files (0.4%
> non contiguous.
>
> on reboot, I had:
>
> /dev/hda5 clean
> /dev/hdc2 clean
> /dev/hdc3 clean
>
> After so many fixings, I rather expected that it would not reboot
> properly, but, so far, I have not found anything wrong in the repaired
> system.
>
> Last june, about the same thing had happened, not on /dev/hda5, but on
> /dev/hdc3. There were so much fixing to be done, that I had given up. This
> time, it happens on a newly re-installed system.
>
> I suppose that a similar problem is going to happen again some time
> sooner or later...
>
> Thanks in advance for any useful input

Essentially it looks like the disk is falling apart.

Get a new disk, and reinstall on that.

Unless its just a system you don't mind losing data on.

Bad block mapping works up to a point, but an increase in the bad block
count shows that something bad is happening inside the disk.

The Natural Philosopher wrote (in part):

> Bad block mapping works up to a point, but an increase in the bad block
> count shows that something bad is happening inside the disk.
>
I thought bad block mapping was obsolete because recent hard drives do this
automatically internally. So by the time the OS notices a bad block, all the
spare blocks for remapping on the hard drives have been used. I.e., the hard
drive is almost dead already any you barely have time (if not already too
late) to get your data off it before it crashes completely.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 07:45:01 up 15 days, 16:54, 4 users, load average: 4.25, 4.18, 4.18

On Tue, 29 Aug 2006 13:20:05 +0200, The Natural Philosopher wrote:

> Bernard wrote:
>> Hi there !
>>
>> Could anyone give me a diagnosis on my hard disk problem ?
>>
>> On an old Fujitsu, I had installed RedHat 6.0, a few years ago. It
>> worked for years
>> without any problem. Then, last june, I had a crash on a partition, and
>> I had to re-install, which I did only last week. At first, everything
>> seemed OK, but, after 2-3 days and about 3 ou 4 shutdown and startup, I
>> ran into a problem similar to that of last june, except that it occured
>> in /dev/hda5 instead of /dev/hdc3 last time :
>>
>> '/dev/hda5 contains a filesystem with errors ! check forced...
>>
>> ... kernel panic, [file system] inconsistency... run fsck manually...'
>>
>> at this point, I typed the root pasword as required, got dropped to a
>> shell, and typed:
>>
>> 'fsck /dev/hda5' :
>>
>> 'PASS 1 : Checking inodes, blocks and sizes... Duplicate blocks found
>> ..... Invoking duplicate block passes... etc...
>>
>> PASS 1B : Rescan for duplicate bad blocks... Duplicate bad blocks in
>> inode 55299 : 221452
>> 55300 : 221453
>> 55301 : 221454
>> ... etc...
>>
>> PASS 1C : Scan directories for inodes with dup blocks ..............
>> PASS 1D : Reconciling duplicate bad blocks
>>
>> file ... (inode 55305, mod time Sat Aug26,2006 has 3 duplicate blocks
>> shared with 3 files.....
>>
>> etc.., etc..,
>> /etc/mail...
>>
>> Clone Duplicate bad blocks => Y
>>
>> Pass 2 : checking directory structure : the '..' in /etc/mail (55299)
>> is missing... FIX => Y
>>
>> PASS 4 : checking reference counts: inode 2 reference count is 15,
>> should be 16 FIX => Y, inode 18433 reference count is 27, should be 26
>> FIX => Y... etc... unattached inode 55301
>>
>> etc...
>>
>> PASS 5 : checking group summary information. Block bitmap differences
>> +221461 +221462 .... 221486... etc...
>>
>> etc... etc... it took at least 15 minutes to fix everything, replying
>> 'Y' to every ask. Then I got :
>>
>> '/dev/hda5 : filesystem was modified. /dev/hda5 6703/110592 files (0.4%
>> non contiguous.
>>
>> on reboot, I had:
>>
>> /dev/hda5 clean
>> /dev/hdc2 clean
>> /dev/hdc3 clean
>>
>> After so many fixings, I rather expected that it would not reboot
>> properly, but, so far, I have not found anything wrong in the repaired
>> system.
>>
>> Last june, about the same thing had happened, not on /dev/hda5, but on
>> /dev/hdc3. There were so much fixing to be done, that I had given up.
>> This time, it happens on a newly re-installed system.
>>
>> I suppose that a similar problem is going to happen again some time
>> sooner or later...
>>
>> Thanks in advance for any useful input
>
> Essentially it looks like the disk is falling apart.
>
> Get a new disk, and reinstall on that.

Yes, but then, why did this happen last june on /dev/hdc3 and now in
/dev/hda5 ? These are two different disks (my PC has 3, the third one
being hdb). It seems curious that, after 8 years of good service, both
disks would give up at the same time or just about... I have heard of PC
lasting 15 years or more...

>
> Unless its just a system you don't mind losing data on.
>
> Bad block mapping works up to a point, but an increase in the bad block
> count shows that something bad is happening inside the disk.

Bernard wrote:

>> Essentially it looks like the disk is falling apart.
>>
>> Get a new disk, and reinstall on that.
>
> Yes, but then, why did this happen last june on /dev/hdc3 and now in
> /dev/hda5 ? These are two different disks (my PC has 3, the third one
> being hdb). It seems curious that, after 8 years of good service, both
> disks would give up at the same time or just about... I have heard of PC
> lasting 15 years or more...

But retail hard drives? The longest I ever got one to run was about 7 years,
running 24/7.

I now have 2 10,000rpm SCSI drives that have over 6 years on them, also
running 24/7. I do not know how much they have left on them. If I were
running a commercial installation, I might consider replacing them on
general principles.

If the failure rate distribution is fairly tight, or if it is just that the
statistics are right, this would not be a surprise that two drives in the
same machine failed within a year of each other.

The alternative is that you are doing something that would cause two drives
to fail within a short interval. Possible though. I was at a location where
there were about 10 machines, each with three removable pack hard drives.
One head crashed. The dust thrown off by this caused the other heads to
crash. ... until all 30 drives had to be totally cleaned up, heads replaced,
etc. (Replacing heads was possible in those days.) Fortunately everything
was backed up daily, so no one lost over a day's work.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 09:35:01 up 15 days, 18:44, 3 users, load average: 4.36, 4.27, 4.21

Bernard wrote:
> On Tue, 29 Aug 2006 13:20:05 +0200, The Natural Philosopher wrote:
>
>> Bernard wrote:
>>> Hi there !
>>>
>>> Could anyone give me a diagnosis on my hard disk problem ?
>>>
>>> On an old Fujitsu, I had installed RedHat 6.0, a few years ago. It
>>> worked for years
>>> without any problem. Then, last june, I had a crash on a partition, and
>>> I had to re-install, which I did only last week. At first, everything
>>> seemed OK, but, after 2-3 days and about 3 ou 4 shutdown and startup, I
>>> ran into a problem similar to that of last june, except that it occured
>>> in /dev/hda5 instead of /dev/hdc3 last time :
>>>
>>> '/dev/hda5 contains a filesystem with errors ! check forced...
>>>
>>> ... kernel panic, [file system] inconsistency... run fsck manually...'
>>>
>>> at this point, I typed the root pasword as required, got dropped to a
>>> shell, and typed:
>>>
>>> 'fsck /dev/hda5' :
>>>
>>> 'PASS 1 : Checking inodes, blocks and sizes... Duplicate blocks found
>>> ..... Invoking duplicate block passes... etc...
>>>
>>> PASS 1B : Rescan for duplicate bad blocks... Duplicate bad blocks in
>>> inode 55299 : 221452
>>> 55300 : 221453
>>> 55301 : 221454
>>> ... etc...
>>>
>>> PASS 1C : Scan directories for inodes with dup blocks ..............
>>> PASS 1D : Reconciling duplicate bad blocks
>>>
>>> file ... (inode 55305, mod time Sat Aug26,2006 has 3 duplicate blocks
>>> shared with 3 files.....
>>>
>>> etc.., etc..,
>>> /etc/mail...
>>>
>>> Clone Duplicate bad blocks => Y
>>>
>>> Pass 2 : checking directory structure : the '..' in /etc/mail (55299)
>>> is missing... FIX => Y
>>>
>>> PASS 4 : checking reference counts: inode 2 reference count is 15,
>>> should be 16 FIX => Y, inode 18433 reference count is 27, should be 26
>>> FIX => Y... etc... unattached inode 55301
>>>
>>> etc...
>>>
>>> PASS 5 : checking group summary information. Block bitmap differences
>>> +221461 +221462 .... 221486... etc...
>>>
>>> etc... etc... it took at least 15 minutes to fix everything, replying
>>> 'Y' to every ask. Then I got :
>>>
>>> '/dev/hda5 : filesystem was modified. /dev/hda5 6703/110592 files (0.4%
>>> non contiguous.
>>>
>>> on reboot, I had:
>>>
>>> /dev/hda5 clean
>>> /dev/hdc2 clean
>>> /dev/hdc3 clean
>>>
>>> After so many fixings, I rather expected that it would not reboot
>>> properly, but, so far, I have not found anything wrong in the repaired
>>> system.
>>>
>>> Last june, about the same thing had happened, not on /dev/hda5, but on
>>> /dev/hdc3. There were so much fixing to be done, that I had given up.
>>> This time, it happens on a newly re-installed system.
>>>
>>> I suppose that a similar problem is going to happen again some time
>>> sooner or later...
>>>
>>> Thanks in advance for any useful input
>> Essentially it looks like the disk is falling apart.
>>
>> Get a new disk, and reinstall on that.
>
> Yes, but then, why did this happen last june on /dev/hdc3 and now in
> /dev/hda5 ? These are two different disks (my PC has 3, the third one
> being hdb). It seems curious that, after 8 years of good service, both
> disks would give up at the same time or just about... I have heard of PC
> lasting 15 years or more...

Mmm. We generally found SCSI disks gave up about 5 years in..

But don't discount the possibility that something - dust, temperature,
or even a power failure - has damaged both at the same point.

However another possibility - that of a failing SCSI controller - exists..

The answer there is to borrow someone else's SCSI machine and try and
mount and fsck the drives on that.

I have to say after many years of trying to be smart with disks, I
simply bin them at the first sign of trouble.

On Tue, 29 Aug 2006 15:46:50 +0200, The Natural Philosopher wrote:

> Bernard wrote:
>> On Tue, 29 Aug 2006 13:20:05 +0200, The Natural Philosopher wrote:
>>
>>> Bernard wrote:
>>>> Hi there !
>>>>
>>>> Could anyone give me a diagnosis on my hard disk problem ?
>>>>
>>>> On an old Fujitsu, I had installed RedHat 6.0, a few years ago. It
>>>> worked for years
>>>> without any problem. Then, last june, I had a crash on a partition,
>>>> and I had to re-install, which I did only last week. At first,
>>>> everything seemed OK, but, after 2-3 days and about 3 ou 4 shutdown
>>>> and startup, I ran into a problem similar to that of last june,
>>>> except that it occured in /dev/hda5 instead of /dev/hdc3 last time :
>>>>
>>>> '/dev/hda5 contains a filesystem with errors ! check forced...
>>>>
>>>> ... kernel panic, [file system] inconsistency... run fsck
>>>> manually...'
>>>>
>>>> at this point, I typed the root pasword as required, got dropped to a
>>>> shell, and typed:
>>>>
>>>> 'fsck /dev/hda5' :
>>>>
>>>> 'PASS 1 : Checking inodes, blocks and sizes... Duplicate blocks found
>>>> ..... Invoking duplicate block passes... etc...
>>>>
>>>> PASS 1B : Rescan for duplicate bad blocks... Duplicate bad blocks in
>>>> inode 55299 : 221452
>>>> 55300 : 221453
>>>> 55301 : 221454
>>>> ... etc...
>>>>
>>>> PASS 1C : Scan directories for inodes with dup blocks ..............
>>>> PASS 1D : Reconciling duplicate bad blocks
>>>>
>>>> file ... (inode 55305, mod time Sat Aug26,2006 has 3 duplicate blocks
>>>> shared with 3 files.....
>>>>
>>>> etc.., etc..,
>>>> /etc/mail...
>>>>
>>>> Clone Duplicate bad blocks => Y
>>>>
>>>> Pass 2 : checking directory structure : the '..' in /etc/mail (55299)
>>>> is missing... FIX => Y
>>>>
>>>> PASS 4 : checking reference counts: inode 2 reference count is 15,
>>>> should be 16 FIX => Y, inode 18433 reference count is 27, should be
>>>> 26 FIX => Y... etc... unattached inode 55301
>>>>
>>>> etc...
>>>>
>>>> PASS 5 : checking group summary information. Block bitmap differences
>>>> +221461 +221462 .... 221486... etc...
>>>>
>>>> etc... etc... it took at least 15 minutes to fix everything, replying
>>>> 'Y' to every ask. Then I got :
>>>>
>>>> '/dev/hda5 : filesystem was modified. /dev/hda5 6703/110592 files
>>>> (0.4% non contiguous.
>>>>
>>>> on reboot, I had:
>>>>
>>>> /dev/hda5 clean
>>>> /dev/hdc2 clean
>>>> /dev/hdc3 clean
>>>>
>>>> After so many fixings, I rather expected that it would not reboot
>>>> properly, but, so far, I have not found anything wrong in the
>>>> repaired system.
>>>>
>>>> Last june, about the same thing had happened, not on /dev/hda5, but
>>>> on /dev/hdc3. There were so much fixing to be done, that I had given
>>>> up. This time, it happens on a newly re-installed system.
>>>>
>>>> I suppose that a similar problem is going to happen again some time
>>>> sooner or later...
>>>>
>>>> Thanks in advance for any useful input
>>> Essentially it looks like the disk is falling apart.
>>>
>>> Get a new disk, and reinstall on that.
>>
>> Yes, but then, why did this happen last june on /dev/hdc3 and now in
>> /dev/hda5 ? These are two different disks (my PC has 3, the third one
>> being hdb). It seems curious that, after 8 years of good service, both
>> disks would give up at the same time or just about... I have heard of
>> PC lasting 15 years or more...
>
> Mmm. We generally found SCSI disks gave up about 5 years in..
>
> But don't discount the possibility that something - dust, temperature,
> or even a power failure - has damaged both at the same point.
>
> However another possibility - that of a failing SCSI controller -
> exists..

But these are not SCSI disks, just IDE disks


> The answer there is to borrow someone else's SCSI machine and try and
> mount and fsck the drives on that.
>
> I have to say after many years of trying to be smart with disks, I
> simply bin them at the first sign of trouble.

If I were sure that those disks are faulty, I would replace them...
provided that I can find such old standard disks for such an old
machine...

On Tue, 29 Aug 2006, in the Usenet newsgroup comp.os.linux.setup, in article
<1156859110.26341.0@damia.uk.clara.net>, The Natural Philosopher wrote:

>Bernard wrote:

>> The Natural Philosopher wrote:

>>> Bernard wrote:

>>>> '/dev/hda5 contains a filesystem with errors ! check forced...

>>> Essentially it looks like the disk is falling apart.
>>>
>>> Get a new disk, and reinstall on that.

>> Yes, but then, why did this happen last june on /dev/hdc3 and now in
>> /dev/hda5 ? These are two different disks (my PC has 3, the third one
>> being hdb). It seems curious that, after 8 years of good service, both
>> disks would give up at the same time or just about... I have heard of PC
>> lasting 15 years or more...

>Mmm. We generally found SCSI disks gave up about 5 years in..

That's nice. Assuming I keep the drives at a reasonable case temperature,
I haven't had that many disk failures. The primary disk on this
workstation is a WD from 1996, and has been running virtually continuously
since new. The drive on the 386SX firewall at home is a Maxtor 213 Meg that
is nearly 19 years old.

>But don't discount the possibility that something - dust, temperature,
>or even a power failure - has damaged both at the same point.

>However another possibility - that of a failing SCSI controller - exists..

How would a failing SCSI controller effect IDE disks?

>The answer there is to borrow someone else's SCSI machine and try and
>mount and fsck the drives on that.

How did you get onto SCSI, when the system having problems is using IDE?
Is that a "whoosh" bird I hear? Since the mid-90s, the IDE controller
(such as it is) has been part of the South-Bridge of the motherboard
chip set. If that's having problems, it's a "chuck the motherboard into
the trash" time.

Old guy

In message <44f474d7$0$22495$626a54ce@news.free.fr>
Bernard <debreil@lcpc.fr> wrote:

> On Tue, 29 Aug 2006 15:46:50 +0200, The Natural Philosopher wrote:
>
>> Bernard wrote:
>>> On Tue, 29 Aug 2006 13:20:05 +0200, The Natural Philosopher wrote:
>>>
>>>> Bernard wrote:
>>>>> Hi there !
>>>>>
>>>>> Could anyone give me a diagnosis on my hard disk problem ?
>>>>>
>>>>> On an old Fujitsu, I had installed RedHat 6.0, a few years ago. It
>>>>> worked for years
>>>>> without any problem. Then, last june, I had a crash on a partition,
>>>>> and I had to re-install, which I did only last week. At first,
>>>>> everything seemed OK, but, after 2-3 days and about 3 ou 4 shutdown
>>>>> and startup, I ran into a problem similar to that of last june,
>>>>> except that it occured in /dev/hda5 instead of /dev/hdc3 last time :
>>>>>
>>>>> '/dev/hda5 contains a filesystem with errors ! check forced...
>>>>>
>>>>> ... kernel panic, [file system] inconsistency... run fsck
>>>>> manually...'
>>>>>
>>>>> at this point, I typed the root pasword as required, got dropped to a
>>>>> shell, and typed:
>>>>>
>>>>> 'fsck /dev/hda5' :
>>>>>
>>>>> 'PASS 1 : Checking inodes, blocks and sizes... Duplicate blocks found
>>>>> ..... Invoking duplicate block passes... etc...
>>>>>
>>>>> PASS 1B : Rescan for duplicate bad blocks... Duplicate bad blocks in
>>>>> inode 55299 : 221452
>>>>> 55300 : 221453
>>>>> 55301 : 221454
>>>>> ... etc...
>>>>>
>>>>> PASS 1C : Scan directories for inodes with dup blocks ..............
>>>>> PASS 1D : Reconciling duplicate bad blocks
>>>>>
>>>>> file ... (inode 55305, mod time Sat Aug26,2006 has 3 duplicate blocks
>>>>> shared with 3 files.....
>>>>>
>>>>> etc.., etc..,
>>>>> /etc/mail...
>>>>>
>>>>> Clone Duplicate bad blocks => Y
>>>>>
>>>>> Pass 2 : checking directory structure : the '..' in /etc/mail (55299)
>>>>> is missing... FIX => Y
>>>>>
>>>>> PASS 4 : checking reference counts: inode 2 reference count is 15,
>>>>> should be 16 FIX => Y, inode 18433 reference count is 27, should be
>>>>> 26 FIX => Y... etc... unattached inode 55301
>>>>>
>>>>> etc...
>>>>>
>>>>> PASS 5 : checking group summary information. Block bitmap differences
>>>>> +221461 +221462 .... 221486... etc...
>>>>>
>>>>> etc... etc... it took at least 15 minutes to fix everything, replying
>>>>> 'Y' to every ask. Then I got :
>>>>>
>>>>> '/dev/hda5 : filesystem was modified. /dev/hda5 6703/110592 files
>>>>> (0.4% non contiguous.
>>>>>
>>>>> on reboot, I had:
>>>>>
>>>>> /dev/hda5 clean
>>>>> /dev/hdc2 clean
>>>>> /dev/hdc3 clean
>>>>>
>>>>> After so many fixings, I rather expected that it would not reboot
>>>>> properly, but, so far, I have not found anything wrong in the
>>>>> repaired system.
>>>>>
>>>>> Last june, about the same thing had happened, not on /dev/hda5, but
>>>>> on /dev/hdc3. There were so much fixing to be done, that I had given
>>>>> up. This time, it happens on a newly re-installed system.
>>>>>
>>>>> I suppose that a similar problem is going to happen again some time
>>>>> sooner or later...
>>>>>
>>>>> Thanks in advance for any useful input
>>>> Essentially it looks like the disk is falling apart.
>>>>
>>>> Get a new disk, and reinstall on that.
>>>
>>> Yes, but then, why did this happen last june on /dev/hdc3 and now in
>>> /dev/hda5 ? These are two different disks (my PC has 3, the third one
>>> being hdb). It seems curious that, after 8 years of good service, both
>>> disks would give up at the same time or just about... I have heard of
>>> PC lasting 15 years or more...
>>
>> Mmm. We generally found SCSI disks gave up about 5 years in..
>>
>> But don't discount the possibility that something - dust, temperature,
>> or even a power failure - has damaged both at the same point.
>>
>> However another possibility - that of a failing SCSI controller -
>> exists..
>
> But these are not SCSI disks, just IDE disks
>
>
>> The answer there is to borrow someone else's SCSI machine and try and
>> mount and fsck the drives on that.
>>
>> I have to say after many years of trying to be smart with disks, I
>> simply bin them at the first sign of trouble.
>
> If I were sure that those disks are faulty, I would replace them...
> provided that I can find such old standard disks for such an old
> machine...

Replace them!

Retail IDE disks seem to have a life of around 3 years. (Older ones,
e.g. <1GByte lasted longer, because when they were made they were
expensive, premium items.)

SCSI disks generally last longer, but I don't have the experience to
suggest how much.

About 4 years ago there were a considerable number of 20GB disks with
a manufactirung fault. The majority of them failed between 2 and 3
years old. We had 15 of them. 1 failed in its first month. 3 more
failed before 2 years. 8 more (including one of the replacements)
failed during the 3rd year. The vendor eventually swapped the lot.

Failure clusters can, and do, happen.

Alan


--
Alan Adams, from Northamptonshire
alan.adams@orchard-way.freeserve.co.uk
http://www.nckc.org.uk/

Bernard wrote:
> On Tue, 29 Aug 2006 15:46:50 +0200, The Natural Philosopher wrote:
>
>> Bernard wrote:
>>> On Tue, 29 Aug 2006 13:20:05 +0200, The Natural Philosopher wrote:
>>>
>>>> Bernard wrote:
>>>>> Hi there !
>>>>>
>>>>> Could anyone give me a diagnosis on my hard disk problem ?
>>>>>
>>>>> On an old Fujitsu, I had installed RedHat 6.0, a few years ago. It
>>>>> worked for years
>>>>> without any problem. Then, last june, I had a crash on a partition,
>>>>> and I had to re-install, which I did only last week. At first,
>>>>> everything seemed OK, but, after 2-3 days and about 3 ou 4 shutdown
>>>>> and startup, I ran into a problem similar to that of last june,
>>>>> except that it occured in /dev/hda5 instead of /dev/hdc3 last time :
>>>>>
>>>>> '/dev/hda5 contains a filesystem with errors ! check forced...
>>>>>
>>>>> ... kernel panic, [file system] inconsistency... run fsck
>>>>> manually...'
>>>>>
>>>>> at this point, I typed the root pasword as required, got dropped to a
>>>>> shell, and typed:
>>>>>
>>>>> 'fsck /dev/hda5' :
>>>>>
>>>>> 'PASS 1 : Checking inodes, blocks and sizes... Duplicate blocks found
>>>>> ..... Invoking duplicate block passes... etc...
>>>>>
>>>>> PASS 1B : Rescan for duplicate bad blocks... Duplicate bad blocks in
>>>>> inode 55299 : 221452
>>>>> 55300 : 221453
>>>>> 55301 : 221454
>>>>> ... etc...
>>>>>
>>>>> PASS 1C : Scan directories for inodes with dup blocks ..............
>>>>> PASS 1D : Reconciling duplicate bad blocks
>>>>>
>>>>> file ... (inode 55305, mod time Sat Aug26,2006 has 3 duplicate blocks
>>>>> shared with 3 files.....
>>>>>
>>>>> etc.., etc..,
>>>>> /etc/mail...
>>>>>
>>>>> Clone Duplicate bad blocks => Y
>>>>>
>>>>> Pass 2 : checking directory structure : the '..' in /etc/mail (55299)
>>>>> is missing... FIX => Y
>>>>>
>>>>> PASS 4 : checking reference counts: inode 2 reference count is 15,
>>>>> should be 16 FIX => Y, inode 18433 reference count is 27, should be
>>>>> 26 FIX => Y... etc... unattached inode 55301
>>>>>
>>>>> etc...
>>>>>
>>>>> PASS 5 : checking group summary information. Block bitmap differences
>>>>> +221461 +221462 .... 221486... etc...
>>>>>
>>>>> etc... etc... it took at least 15 minutes to fix everything, replying
>>>>> 'Y' to every ask. Then I got :
>>>>>
>>>>> '/dev/hda5 : filesystem was modified. /dev/hda5 6703/110592 files
>>>>> (0.4% non contiguous.
>>>>>
>>>>> on reboot, I had:
>>>>>
>>>>> /dev/hda5 clean
>>>>> /dev/hdc2 clean
>>>>> /dev/hdc3 clean
>>>>>
>>>>> After so many fixings, I rather expected that it would not reboot
>>>>> properly, but, so far, I have not found anything wrong in the
>>>>> repaired system.
>>>>>
>>>>> Last june, about the same thing had happened, not on /dev/hda5, but
>>>>> on /dev/hdc3. There were so much fixing to be done, that I had given
>>>>> up. This time, it happens on a newly re-installed system.
>>>>>
>>>>> I suppose that a similar problem is going to happen again some time
>>>>> sooner or later...
>>>>>
>>>>> Thanks in advance for any useful input
>>>> Essentially it looks like the disk is falling apart.
>>>>
>>>> Get a new disk, and reinstall on that.
>>> Yes, but then, why did this happen last june on /dev/hdc3 and now in
>>> /dev/hda5 ? These are two different disks (my PC has 3, the third one
>>> being hdb). It seems curious that, after 8 years of good service, both
>>> disks would give up at the same time or just about... I have heard of
>>> PC lasting 15 years or more...
>> Mmm. We generally found SCSI disks gave up about 5 years in..
>>
>> But don't discount the possibility that something - dust, temperature,
>> or even a power failure - has damaged both at the same point.
>>
>> However another possibility - that of a failing SCSI controller -
>> exists..
>
> But these are not SCSI disks, just IDE disks
>
>
>> The answer there is to borrow someone else's SCSI machine and try and
>> mount and fsck the drives on that.
>>
>> I have to say after many years of trying to be smart with disks, I
>> simply bin them at the first sign of trouble.
>
> If I were sure that those disks are faulty, I would replace them...
> provided that I can find such old standard disks for such an old
> machine...

No chance a modern IDE drive will fit?

IDE drives don;t generally do more than 3-5 years at best.

I'd go about 10:1 that the disks are just on their last legs.

Surely a modern IDE drive will fit? Even if you can't use all of it...