[GLLUG] Disk issue?

Sat Apr 21 07:43:57 EDT 2012

That is nonsense. Disks don't always go bad. There are why you monitor 
them to see if they are getting worse.

I will agree that replacing them is desirable. But in many cases that is 
not an option.

Disks have developed bad blocks since the first hard drive. It is a fact 
of life.

Drives are getting bigger and more cheaply made all the time.  Would you 
throw out a 1T drive because it has 1M of bad blocks on it?

On 04/20/2012 09:49 PM, STeve Andre' wrote:
> This is *really* bad advice.
>
> When a disk starts going, it needs to be replaced.  You have NO IDEA of
> what is going on inside, and things may be stable, get slowly worse, or
> completely collapse with no notice.
>
> I have dealt with too many disk disasters in the last couple of years.
>
> Disks are cheap, time is expensive, and data can be irreplaceable.  Please
> don't do this.  It *will* nip you when you can least afford it.
>
> --STeve Andre'
>
> On 04/20/12 20:35, bfdamkoehler wrote:
>>
>> It certainly indicates that the drive has issues. I have had several 
>> number of problems with bad blocks on drives in the past year or two 
>> after many, many years of no problems. One of them continued to get 
>> worse and one never changed after getting a batch of bad blocks.
>>
>> However, it doesn't means that the drive is completely toast. Once I 
>> start getting the bad blocks I used badblocks once a week or so 
>> (assuming that the drive is usable at all) to see if it is getting 
>> worse. This will also tell you what percentage of the disk is bad, 
>> which may help determine if you want to scrap the drive or not.
>>
>> I start by mapping the bad blocks out to prevent future problems. You 
>> will lose the data that was stored in the bad block, but you will 
>> retain the rest of the disk.
>>
>> You can also use tools like dd_rescue to make an image of the disk 
>> with the bad blocks replaced with whatever it supplies on errors, 
>> probably zero bytes.
>>
>>
>>
>> On 04/20/2012 09:45 AM, Marshal Newrock wrote:
>>> Yes, the drive is probably toast.  The error is saying it encountered a
>>> bad sector and can't read the drive.  Of course, there's always a slim
>>> chance that it's a bad data cable or connection, but you should assume
>>> that the drive is now dead.  If you don't have current backups of
>>> everything on that drive, good luck.
>>>
>>> Marshal
>>>
>>>
>>> On Fri, 20 Apr 2012 09:34:01 -0400
>>> J Neveau<neveauj at gmail.com>  wrote:
>>>
>>>> Anyone ever seen any of this kind of output in dmesg before?  Might
>>>> this be indicative of a drive failure?
>>>>
>>>> [    1.501112] sd 5:0:0:0: [sdf] 78165360 512-byte logical blocks:
>>>> (40.0 GB/37.2 GiB)
>>>> [    1.501193] sd 5:0:0:0: [sdf] Write Protect is off
>>>> [    1.501197] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00
>>>> [    1.501231] sd 5:0:0:0: [sdf] Write cache: enabled, read cache:
>>>> enabled, doesn't support DPO or FUA
>>>> [    1.501439]  sdf:
>>>> [    1.520956]  sdf1
>>>> [    1.521467] sd 5:0:0:0: [sdf] Attached SCSI disk
>>>> [   55.184708] sd 5:0:0:0: [sdf] Unhandled sense code
>>>> [   55.184710] sd 5:0:0:0: [sdf] Result: hostbyte=DID_OK
>>>> driverbyte=DRIVER_SENSE
>>>> [   55.184714] sd 5:0:0:0: [sdf] Sense Key : Medium Error [current]
>>>> [descriptor]
>>>> [   55.184733] sd 5:0:0:0: [sdf] Add. Sense: Unrecovered read error -
>>>> auto reallocate failed
>>>> [   55.184739] sd 5:0:0:0: [sdf] CDB: Read(10): 28 00 03 d0 00 4f 00
>>>> 00 40 00
>>>> [   55.184748] end_request: I/O error, dev sdf, sector 63963215
>>>> [   55.184753] Buffer I/O error on device sdf1, logical block 31981576
>>>> [   55.184758] Buffer I/O error on device sdf1, logical block 31981577
>>>> [   55.184762] Buffer I/O error on device sdf1, logical block 31981578
>>>> [   55.184765] Buffer I/O error on device sdf1, logical block 31981579
>>>> [   55.184774] Buffer I/O error on device sdf1, logical block 31981580
>>>> [   55.184777] Buffer I/O error on device sdf1, logical block 31981581
>>>> [   55.184781] Buffer I/O error on device sdf1, logical block 31981582
>>>> [   55.184784] Buffer I/O error on device sdf1, logical block 31981583
>>>> [   55.184788] Buffer I/O error on device sdf1, logical block 31981584
>>>> [   55.184792] Buffer I/O error on device sdf1, logical block 31981585
>>>> [   79.656711] sd 5:0:0:0: [sdf] Unhandled sense code
>>>> [   79.656713] sd 5:0:0:0: [sdf] Result: hostbyte=DID_OK
>>>> driverbyte=DRIVER_SENSE
>>>> [   79.656717] sd 5:0:0:0: [sdf] Sense Key : Medium Error [current]
>>>> [descriptor]
>>>> [   79.656736] sd 5:0:0:0: [sdf] Add. Sense: Unrecovered read error -
>>>> auto reallocate failed
>>>> [   79.656742] sd 5:0:0:0: [sdf] CDB: Read(10): 28 00 03 d0 00 4f 00
>>>> 00 08 00
>>>> [   79.656750] end_request: I/O error, dev sdf, sector 63963215
>>>> [   79.656758] Buffer I/O error on device sdf1, logical block 31981576
>>>> [   79.656763] Buffer I/O error on device sdf1, logical block 31981577
>>>> [   79.656767] Buffer I/O error on device sdf1, logical block 31981578
>>>> [   79.656770] Buffer I/O error on device sdf1, logical block 31981579
>>>> [  103.968729] sd 5:0:0:0: [sdf] Unhandled sense code
>>>> [  103.968731] sd 5:0:0:0: [sdf] Result: hostbyte=DID_OK
>>>> driverbyte=DRIVER_SENSE
>>>> [  103.968735] sd 5:0:0:0: [sdf] Sense Key : Medium Error [current]
>>>> [descriptor]
>>>> [  103.968754] sd 5:0:0:0: [sdf] Add. Sense: Unrecovered read error -
>>>> auto reallocate failed
>>>> [  103.968760] sd 5:0:0:0: [sdf] CDB: Read(10): 28 00 03 d0 00 4f 00
>>>> 00 08 00
>>>> [  103.968768] end_request: I/O error, dev sdf, sector 63963215
>>>> [  103.968774] Buffer I/O error on device sdf1, logical block 31981576
>>>> [  103.968779] Buffer I/O error on device sdf1, logical block 31981577
>>>> [  103.968783] Buffer I/O error on device sdf1, logical block 31981578
>>>> [  103.968786] Buffer I/O error on device sdf1, logical block 31981579
>>>> [  235.691023] EXT3 FS on sdf1, internal journal
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.egr.msu.edu/mailman/public/linux-user/attachments/20120421/c8629554/attachment.html>