On Thu, Jan 7, 2010 at 8:59 PM, dong wu <dongwucs@xxxxxxxxx> wrote: > In the source code of raid5,when write error,it faulty the disk,not remap > the block. why do it use "remap the block"? > > 2010/1/8, dong wu <dongwucs@xxxxxxxxx>: >> If it is written to the same block,will it read error again? >> when read error,the low-level attempts a write and remap the block if >> the write fails. >> where does it remap? >> Is there any spare block in the disk for remap when read or write error occurs? >> >> 2010/1/7, Robin Hill <robin@xxxxxxxxxxxxxxx>: >> > On Thu Jan 07, 2010 at 08:41:20PM +0800, dong wu wrote: >> > >> > > when read error and can rewrite,where do we rewrite? >> > > It can't be rewrited to the old block. >> > > It should be rewrite to other place,where can we find the 'other place'? >> > > In the source code,I don't find the place that should be rewrited to. >> > > >> > It's rewritten to the same block - it's up to the low-level device (the >> > disk) to attempt a write and transparently remap the block if the write >> > fails. >> > >> > Cheers, >> > Robin >> > -- >> > ___ >> > ( ' } | Robin Hill <robin@xxxxxxxxxxxxxxx> | >> > / / ) | Little Jim says .... | >> > // !! | "He fallen in de water !!" >> > >> > >> > -- > 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 > Modern mass storage devices provide an /abstraction/ of a linear storage device which needn't actually be so. On most of them data plus some extra parity for recovery are stored; if the drive has unusual trouble reading the data back, it will try to get a good read/repair and then use another, spare (reserved), area on the device in place of the one that 'went bad'. This is actually a major problem for cryptographic/security concerns, and is one possible metric in S.M.A.R.T. data that can indicate a failing drive. -- 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
