Re: Why not just return an error?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/10/16 11:01, Brad Campbell wrote:
> On 11/10/16 17:18, Wols Lists wrote:
>> On 11/10/16 05:00, Brad Campbell wrote:
> 
>>>> The point is that the disk sector is not bad. So you don't want to mark
>>>> it as bad on the disk. But you know that the *data* in that block is
>>>> bad, so you want the disk access layer to fake a read error when you
>>>> try
>>>> to read it. The intent is to deliberately trigger a rewrite by md.
>>>
>>> I suggested this a while ago. Take the badblocks log, use hdparm to mark
>>> each bad sector as bad and put the drive back in the array. I even
>>> suggested potentially adding a feature to ddrescue to auto-mark the
>>> blocks as bad on the target drive.
>>
>> But does that mean that the drive thinks those sectors are bad, and that
>> they're then lost permanently at the hardware level? That's what I
>> thought the badblocks list did with hdparm, and that's what I was trying
>> to avoid.
> 
> I've not used bad blocks list, but a cursory read would indicate it only
> records a bad block if the writeback fails. That won't ever happen with
> a bad sector created with hdparm. All hdparm does is corrupt the EEC on
> the block so a read always returns dud. A write solves that issue nicely.
> 
That's good to know. What happened with that suggestion for ddrescue?
Did they not like it, or was it the usual "show us the code and we'll
add it"? :-) So much to do, so little time :-)

I'm trying to build a little list of projects, partly as a result of
doing the wiki, that people wanting to get into raid programming (myself
included!) can do.

Cheers,
Wol

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux