linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: foo saa <foosaa@gmail.com>
To: Mark Lord <kernel@teksavvy.com>
Cc: 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, 4 Mar 2010 10:33:52 -0500	[thread overview]
Message-ID: <f875e2fe1003040733h20d5523ex5d18b84f47fee8c7@mail.gmail.com> (raw)
In-Reply-To: <4B8FC6AC.4060801@teksavvy.com>

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 <kernel@teksavvy.com> 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, 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 15:33 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 [this message]
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=f875e2fe1003040733h20d5523ex5d18b84f47fee8c7@mail.gmail.com \
    --to=foosaa@gmail.com \
    --cc=akpm@linux-foundation.org \
    --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).