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