From: Robert Hancock <hancockrwd@gmail.com>
To: s ponnusa <foosaa@gmail.com>
Cc: Mark Lord <kernel@teksavvy.com>,
Greg Freemyer <greg.freemyer@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
Jens Axboe <jens.axboe@oracle.com>,
linux-mm@kvack.org
Subject: Re: Linux kernel - Libata bad block error handling to user mode program
Date: Thu, 04 Mar 2010 19:58:51 -0600 [thread overview]
Message-ID: <4B90655B.4000005@gmail.com> (raw)
In-Reply-To: <f875e2fe1003041020t7cbab2c2x585df9b2dfc10dd2@mail.gmail.com>
On 03/04/2010 12:20 PM, s ponnusa wrote:
> 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
> well.
>
> 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.
There's nothing in libata which will cause the operation to eventually
return success if the drive keeps failing it (at least there definitely
should not be and I very much doubt there is). My guess is that somehow
what you think should be happening is not what the drive is actually
doing (maybe one of the retries you're seeing is actually succeeding in
writing to the disk, or at least the drive reports it was).
You haven't posted any of the actual kernel output you're seeing, so
it's difficult to say exactly what's going on. However, attempting to
scan for disk errors using writes seems like a flawed strategy. As
several people have mentioned, drives can't necessarily detect errors on
a write.
>
> Thank you.
>
> On Thu, Mar 4, 2010 at 12:49 PM, Mark Lord<kernel@teksavvy.com> 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-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-03-05 1:58 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f875e2fe1003032052p944f32ayfe9fe8cfbed056d4@mail.gmail.com>
2010-03-04 6:42 ` Linux kernel - Libata bad block error handling to user mode program Andrew Morton
2010-03-04 12:58 ` foo saa
2010-03-04 16:31 ` Mike Hayward
2010-03-04 18:12 ` s ponnusa
2010-03-05 0:42 ` Mike Hayward
2010-03-05 2:23 ` s ponnusa
2010-03-05 16:31 ` Mike Hayward
2010-03-05 6:01 ` Greg Freemyer
2010-03-05 13:04 ` Alan Cox
2010-03-04 16:37 ` Mike Hayward
2010-03-04 18:23 ` s ponnusa
2010-03-04 14:17 ` Greg Freemyer
2010-03-04 14:41 ` Mark Lord
2010-03-04 15:33 ` foo saa
2010-03-04 17:49 ` Mark Lord
2010-03-04 18:20 ` s ponnusa
2010-03-04 19:41 ` Greg Freemyer
2010-03-04 19:50 ` s ponnusa
2010-03-05 1:58 ` Robert Hancock [this message]
2010-03-05 2:11 ` s ponnusa
2010-03-05 2:16 ` Robert Hancock
2010-03-05 2:17 ` s ponnusa
2010-03-05 12:03 ` Alan Cox
2010-03-05 22:27 ` s ponnusa
2010-03-11 18:29 ` Greg Freemyer
2010-03-13 22:44 ` s ponnusa
2010-03-13 23:44 ` Robert Hancock
2010-03-14 0:12 ` s ponnusa
2010-03-14 5:06 ` Robert Hancock
2010-03-14 16:02 ` Mark Lord
2010-03-14 16:12 ` Greg Freemyer
2010-03-04 18:40 Kalra Ashish-B00888
-- strict thread matches above, loose matches on Subject: below --
2010-03-04 18:41 Kalra Ashish-B00888
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B90655B.4000005@gmail.com \
--to=hancockrwd@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=foosaa@gmail.com \
--cc=greg.freemyer@gmail.com \
--cc=jens.axboe@oracle.com \
--cc=kernel@teksavvy.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).