linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: s ponnusa <foosaa@gmail.com>
To: Mike Hayward <hayward@loup.net>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-ide@vger.kernel.org, jens.axboe@oracle.com,
	linux-mm@kvack.org
Subject: Re: Linux kernel - Libata bad block error handling to user mode program
Date: Thu, 4 Mar 2010 13:12:59 -0500	[thread overview]
Message-ID: <f875e2fe1003041012m680ffc87i50099ed011526440@mail.gmail.com> (raw)
In-Reply-To: <201003041631.o24GVl51005720@alien.loup.net>

The write cache is turned off at the hdd level. I am using O_DIRECT
mode with aligned buffers of the 4k page size. I have turned off the
page cache and read ahead during read as well using the fadvise
function.

As you have mentioned, the program grinds the hdd when it hits the bad
sector patch. It retries to remap / write again until it (hdd) fails.
It then finds the hdd does not respond and finally resets the device.
(This goes on and the program eventually moves on the next sector
because write call returned success. No errno value was set. Is this
how a write will function in linux? It does not propagate the error to
the user mode program for any reasons related to the disk failures
during a write process even with the O_DIRECT flag.

Is there any specific location, that can be used to turn off the
sector remapping, retrying option at the libata level (I don't want to
change it at the public repository, rather I would like to change in
my kernel for testing / debugging purposes) and propagating the error
to the usermode programs? The messages in syslog are due to the printk
calls at the libata-eh.c file in the drivers/ata section of the kernel
code. But I have not spend much analysing it though.

Thanks.

On Thu, Mar 4, 2010 at 11:31 AM, Mike Hayward <hayward@loup.net> wrote:
> I have seen a couple of your posts on this and thought I'd chime in
> since I know a bit about storage.
>
> I frequently see io errors come through to user space (both read and
> write requests) from usb flash drives, so there is a functioning error
> path there to some degree.  When I see the errors, the kernel is also
> logging the sector and eventually resetting the device.
>
> There is no doubt a disk drive will slow down when it hits a bad spot
> since it will retry numerous times, most likely trying to remap bad
> blocks.  Of course your write succeeded because you probably have the
> drive cache enabled.  Flush or a full cache hangs while the drive
> retries all of the sectors that are bad, remapping them until finally
> it can remap no more.  At some point it probably returns an error if
> flush is timing out or it can't remap any more sectors, but it won't
> include the bad sector.
>
> I would suggest turning the drive cache off.  Then the drive won't lie
> to you about completing writes and you'll at least know which sectors
> are bad.  Just a thought :-)
>
> - Mike
>

--
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>

  reply	other threads:[~2010-03-04 18:13 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 [this message]
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
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=f875e2fe1003041012m680ffc87i50099ed011526440@mail.gmail.com \
    --to=foosaa@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hayward@loup.net \
    --cc=jens.axboe@oracle.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).