Apparently conflicting smartctl output

[Warren Block]

On Fri, 6 Jan 2012, Bas Smeelen wrote:

> On 01/06/2012 04:37 PM, Warren Block wrote:
>> On Fri, 6 Jan 2012, Bas Smeelen wrote:
>> 
>>> On 01/06/2012 03:39 PM, Warren Block wrote:
>>>> On Fri, 6 Jan 2012, Bas Smeelen wrote:
>>>> 
>>>>> I have had this with a drive and multiple read errors would not remap 
>>>>> the
>>>>> sector.
>>>>> With write errors the sector would be remapped. This was a new Samsung
>>>>> laptop drive though, not a Western Digital.
>>>> 
>>>> That's standard.  Sectors are only remapped to spares on a write error.
>>>> 
>>>>> To get the sector remapped I had to fully write the drive and it was ok
>>>>> after that.
>>>> 
>>>> Just writing to the sector should be enough.  Of course, when one sector
>>>> goes bad, others often follow.
>>> 
>>> I just hope it does not develop more bad sectors.
>> 
>> That's the worrying thing.  Was it just a loose flake of oxide, or was it a 
>> strip that peeled off the disk?
>
> No way to know I guess
>> 
>>>> From what I read on the "Bad block HOWTO for smartmontools" on 
>>>> sourceforge
>>> it's not trivial to just write to that sector and also it would destroy 
>>> the
>>> filesystem?
>> 
>> Finding the right block may not be too hard.  /var/log/messages should show 
>> the block number, but then I don't know what tool is available to write to 
>> that specific block.  Tools like that are not common because generally, 
>> growing bad sectors means the drive is starting to fail anyway.
>
> I could use dd if=/dev/random of=file seek=blocks_to_skip bs=100M the next 
> time

Yes, if you're not worried about existing data.  But use /dev/zero 
(faster and you can verify the value) and bs=1M count=100 (ties up only 
1M of buffer space).