I "embargoed" the bad sector with partitioning to get the user back up and running. In the course of an OS X install, it managed to create a "recovery/boot" partition right on top of the bad sector. It no longer returns a read error for that sector. Clearly it was fixed with whatever write command the installer used, and dd as I used it just does something different and fails. There are more pending sectors so once I find their LBAs with SMART offline testing I'll try the other mentioned techniques. What I'm still confused about is, an ATA secure erase had been done and yet the Current_Pending_Sector count was still 48, before and after the secure erase. That tells me that secure erase is just about zeroing and the drive firmware isn't actually confirming if the writes were successful. Tragic. I'd have thought it would write such sectors, confirm they're bad, and remove them from use in one whack, this is apparently not the case. On Jun 6, 2014, at 7:51 PM, Roman Mamedov <rm@xxxxxxxxxxx> wrote: > Try again with "oflag=direct"; > > If that doesn't help, remember this is a 4K-sector drive, maybe you should > retry with bs=4096 (recalculating the offset so it still writes to the proper > place). # smartctl -t select,430195536-max /dev/sda The next bad LBA reported by SMART is 430235856. # dd if=/dev/sda skip=430235856 count=1 | hexdump -C dd: error reading ‘/dev/sda’: Input/output error 0+0 records in 0+0 records out 0 bytes (0 B) copied, 6.97353 s, 0.0 kB/s # dd if=/dev/zero of=/dev/sda seek=430235856 count=1 dd: writing to ‘/dev/sda’: Input/output error 1+0 records in 0+0 records out 0 bytes (0 B) copied, 3.69641 s, 0.0 kB/s # dd if=/dev/zero of=/dev/sda seek=430235856 count=8 8+0 records in 8+0 records out 4096 bytes (4.1 kB) copied, 2.50232 s, 1.6 kB/s # dd if=/dev/sda skip=430235856 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes (512 B) copied00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| , 0.287629 s, 1.8 kB/s * 00000200 ###This command with count=8 worked. I don't know why it worked this time, it didn't with the earlier LBA. When I issue the read command above piped through hexdump that had failed, now it works. Further when I check smart attributes, the current pending sector count has dropped by a value of 8. That seems conclusive the bad sector has been remapped. So I'll keep doing selective offline tests to find bad sectors, and write to them this way and report back. Chris Murphy -- 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
