Adding Mark Lord to CC because hdparm may be part of the problem. On Thu, Jul 8, 2010 at 1:14 PM, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote: > All, > > I just ran a test against a IDE drive (/dev/sdb) and slightly older > kernel (2.6.32). > > Similar to: > > dd if=/dev/sdb of=/dev/null conv=noerror,sync bs=4k > > With a good drive it ran fine. > > Then I used hdparm --make-bad-sector to intentionally corrupt a sector > on the drive. > > When I re-ran it, /var/log/messages reported 10 bad logical blocks. > And even worse, dd reported 20 bad blocks. I examined the data dd > read and it had 80KB of zero'ed out data. So that's 160 sectors worth > of data lost because of a single bad sector. At most I was expecting > 4KB of zero'ed out data. > > I haven't started troubleshooting, but I want to know if this is > expected behavior due to read-ahead or something. (Is there > read-ahead on the raw device, or just if a file system is involved.) > > I can redo my test with 2.6.34 and get logs if that is a bug. > > And if not a bug, is there a hdparm command I can issue to eliminate > this behaviour. > > Thanks > Greg I retested with 2.6.25 and see the same behavior, so if its a bug, its not a recently introduced one. But 2.6.25 is showing a lot more media errors than I recall from 2.6.32. Even stranger, I'm now introducing the bad sector as sector 100,000 (ie. about 50 MB from the start of the drive). Then doing a dd to capture just the first 100 MB to a file. ie. dd if=/dev/sdb of=clean.dd conv=noerror,sync bs=4K count=25600 hdparm --make-bad-sector 100000 --yes-i-know-what-i-am-doing /dev/sdb dd if=/dev/sdb of=corrupt.dd conv=noerror,sync bs=4K count=25600 hdparm --write-sector 100000 --yes-i-know-what-i-am-doing /dev/sdb (clearly don't do that to a disk you care about. The data at sector 100,000 is permanently lost.) cmp -bl clean.dd corrupt.dd > delta.log Looking at delta.log, the bytes start disagreeing 4 bytes prior to the sector boundary. How can that be? I guess hdparm --make-bad-sector may be corrupting an extra 4 bytes, but that would surprise me. That seems like a definite bug in either the kernel or hdparm. Mark, do you have any input about either the early start of the corruption, or the very large number of sectors that seem corrupted by making a single sector bad. Greg -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
