On 14/01/11 10:05, James Courtier-Dutton wrote:
> On 14 January 2011 09:42, Chris Dennis<cgdennis@???> wrote:
>> On 13/01/11 15:30, Hugo Mills wrote:
>>>
>>> On Thu, Jan 13, 2011 at 03:23:30PM +0000, Chris Dennis wrote:
>>>>
>>>> Hello folks
>>>>
>>>> I've come across a problem on a friend's computer.
>>>>
>>>> The computer is fairly old (see below), running Ubuntu 10.10, with /
>>>> on a 40GB IDE drive, and /home on a 120GB Maxtor SATA drive.
>>>>
>>>> It's /home that's the problem. It's on a single partition
>>>> /dev/sda1, formatted as ext4. I've run the Maxtor diagnostics on
>>>> the drive, and no problems were reported.
>>>>
>>>> Ubuntu wants to check the filing system on every boot. Running
>>>> 'fsck -f' manually (from Knoppix 6.2) gives:
>>>>
>>>> Block bitmap differences:<some number ranges, different each time>
>>>>
>>>> Sometimes it also offers to fix:
>>>>
>>>> Free blocks count wrong for group #<numbers that change each time>
>>>>
>>>> I choose to fix those problems, but they're still there next time.
>>>>
>>>> I've also run 'fsck -fc /dev/sda1' -- it didn't report any bad
>>>> blocks, and the other were still there.
>>>
>>> This smacks to me of a disk that's constantly remapping duff
>>> sectors into spares, and finding more duff sectors. Replace the
>>> hardware ASAP.
>>>
>>> [...]
>>>>
>>>> ran fsck again, and the errors have returned!
>>>>
>>>> Why would copying data into a filing system cause errors like that?
>>>
>>> Bad hardware.
>>>
>>> Hugo.
>>
>> Thanks for your reply Hugo.
>>
>> I'd have thought the same if the initial disk scan hadn't been OK.
>>
>> So I did some more checks:
>>
>> * older Maxtor diagnostics -- no errors.
>> * latest Seatools diagnostics -- no errors.
>> * SMART (via HDAT2 CD) -- only one error in lifetime of disk,
>> no reallocated sectors, no pending or uncorrectable errors.
>> * SMART extended offline test -- no errors.
>>
>> Then I ran
>>
>> mkfs.ext3 -c -c /dev/sda1
>>
>> with full read-write checks for bad blocks -- it found none, and SMART still
>> reports no reallocated sectors.
>>
>> fsck on the empty filing system was OK. Copied all the data back as before
>> (about 30GB), and fsck is still happy.
>>
>> Note that I've now made the partition ext3 instead of ext4. Would that make
>> a difference? I did notice that when running fsck on the ext4 partition,
>> the first 4 passes were almost instantaneous; only pass 5 'Checking group
>> summary information' took a bit longer, and detected the errors. With ext3,
>> pass 1 takes much longer (i.e. 10 seconds instead of less than 1).
>>
>> Anyway, the data is all backed up, so I'll see how it goes for a while,
>> unless anyone can think of any other tests I can run on the drive.
>>
>> cheers
>>
>> Chris
>
> I had problems with a Maxtor HD recently.
> smart reported no problems at all, but when trying to read all the
> sectors on the HD with ddrescue it has quite a few non-readable
> sectors.
> I concluded that the SMART functionality on Maxtor 2.5 HDs is worthless.
> At least with Seagate HDs, the SMART functionality actually reports problems.
>
> I suggest you do a ddrescue or someother backup method on the failing
> HD you have ASAP, and then do repairs to a copy of the HD image that
> ddrescue creates.
> Remember that every time the drive heads pass over the disk surface it
> is likely to cause more damage, so every repair or read attempt you
> make is likely to result in more sectors going bad.
I've already backed up the data. I haven't tried to dd from the whole
partition, but I have run 'badblocks -w' (as part of 'mkfs -c -c' above)
which reads and writes every block, and that reported no problems.
cheers
Chris
--
Chris Dennis cgdennis@???
Fordingbridge, Hampshire, UK
