From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Greg Freemyer <greg.freemyer@gmail.com>
Cc: Mike Hayward <hayward@loup.net>,
foosaa@gmail.com, 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: Fri, 5 Mar 2010 13:04:26 +0000 [thread overview]
Message-ID: <20100305130426.1c9414d1@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <87f94c371003042201n72ce8578vc01331678b52da75@mail.gmail.com>
> For clarity, most ATA class disk drives are spec'ed to have one
> non-recoverable error per 150TB or so of writes. Disk drives do blind
> writes. (ie. They are not verified). So we should all expect to have
> the occasional silent data corruption on write. The problem is
> compounded with bad cables, controllers, RAM, etc.
Cable errors should only be a PATA issue, SATA protects the command block
and the data.
> The only way for the linux kernel even attempt to fix that is for it
> to do a read verify on everything it writes. For the vast majority of
> uses that is just not acceptable for performance reasons.
It's also the wrong layer
> OTOH, if data integrity is of the utmost for you, then you should
> maintain a md5hash or similar for your critical files and verify them
> any time you make a copy. btrfs may offer a auto read-verify. I
> don't know much about btrfs.
If you deal with utterly enormous amounts of data (as some clusters and
the like do) you protect your data from application to application layer.
It leaves ECC protected memory and it comes back to ECC protected memory
with a hash. That covers a lot of the errors by the OS, hardware, cables,
busses - even drive memory.
--
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 13:01 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 ` 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 [this message]
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
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=20100305130426.1c9414d1@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=akpm@linux-foundation.org \
--cc=foosaa@gmail.com \
--cc=greg.freemyer@gmail.com \
--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