On Jan 14, 2014, at 12:37 PM, Roman Mamedov <rm@xxxxxxxxxxx> wrote: > > I vaguely remember having some drives that were not able to remap a single > block on write, but doing that successfully if I overwrote a sizable area > around (and including) that block, or overwrite the whole drive. And after > that they worked without issue not exhibiting further bad blocks. Presumably the SMART self-assessment for this drive was FAIL? And if so what's the point of the work around when we only have a pass/fail level granularity for drive health? > > Or for example consider the 4k sector drives. If even any portion of the > physical 4k sector is corrupt, some of the eight 512 virtual blocks will be > unreadable; but the thing is, writing to ANY of them individually will fail, > because the drive's internal r-m-w will fail to obtain all the pieces of the > 4k sector from disk to overwrite it. > > So in my opinion one (and perhaps one of the easier) things to consider here, > would be to try being "generous" in recovery-overwrite, say, rewrite a > whole 1MB-sized region centered at the unreadable sector. Not if the SMART status is a FAIL. And if it's not a fail then that sounds like a firmware bug. A better feature would be a way to send a command to the firmware to persistently increase the reserve sectors at the expensive of available space - in effect it reduces the LBA count by e.g. 10MB, thereby increasing the reserve pool by 10MB. Changing this setting in either directionwould obviously mean data loss; but at least it's managed by firmware which transports the accumulated knowledge. Otherwise these block files are going to be backed up, or subject to btrfs send. And then restored invariably in the wrong location on the same drive, or unnecessarily restored onto a new drive so then you need exception code if you don't want that behavior. I think it's trouble. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
