[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
SMART data consists only the count of remapped sectors, seek failures,
raw read error rate, uncorrectable sector counts, crc errors etc., and
technically one should be aware of the error during write operation as

As per the ATAPI specifications, the media will report error for both
read / write operations. It times out / sends out error code for both
read and write operations. Correct me if I am wrong. What happens if
all the available free sectors are remapped and there are no more
sectors to map? In that atleast the drive should return an error
right? When using the O_DIRECT more, the i/o error, media bad,
softreset, hardreset error messages are starting to fill up dmesg
almost immediately after the write call.

It just tries in a continous loop and then finally returns success
(even without remapping). I don't know how to change the behavior of
libata / or other such driver which does it. All I want to do it to
know the error in my program while it is reporting it in the syslog at
kernel / driver level.

Thank you.

On Thu, Mar 4, 2010 at 12:49 PM, Mark Lord <> wrote:
> On 03/04/10 10:33, foo saa wrote:
> ..
>> 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.
> ..
> Oh.. but isn't that information in the S.M.A.R.T. data ??
> You'll not find the bad sectors by writing -- a true WRITE nearly never
> reports a media error.  Instead, the drive simply remaps to a good sector
> on the fly and returns success.
> Generally, only READs report media errors.
> 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 19:23    [W:0.111 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site