[lkml]   [2010]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux kernel - Libata bad block error handling to user mode program
I am using 4k aligned buffers for writing and reading.

Kernel / driver catches the error during the write cycle and I can get
the error messages about the media being bad or sector i/o errors. But
it is not propagated to the program and write always passes (even in
the case of the device being out of control. (i.e., the device fails
to respond to any further open / read / write queries and inaccessible
from the core). Isn't the error has to be notified to the program that
makes the call?

Reading is a completely different scenario and I am disabling the
read-ahead cache completely with fadvise call.

hdparm is good, but I don't want to use the internal ATA SECURE ERASE
because I can never get the amount of bad sectors the drive had.

On Thu, Mar 4, 2010 at 9:41 AM, Mark Lord <> wrote:
> On 03/04/10 09:17, Greg Freemyer wrote:
> ..
>> I think / suspect your major problem is you say above that you use a
>> 512-byte buffer to wipe with.  The kernel is using 4K pages.  So when
>> you write to a 4K section of the drive for the first time, the kernel
>> implements read-modify-write logic.
>> Your i/o failures are almost certainly on the read cycle of the above,
>> not the write cycle.  You need to move to 4K buffers and you need to
>> ensure your 4K writes are aligned with how the kernel is working with
>> the disk.  ie. You need your 4K buffer to perfectly align with the
>> kernels 4K block handling so you never have a read-modify-write cycle.
> ..
> You'll also need to disable Linux read-ahead for the drive,
> or it may try reading beyond even the 4KB block.
> But really.. isn't "hdparm --security-erase NULL /dev/sdX" good enough ???
> Cheers
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2010-03-04 16:37    [W:0.146 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site