From: Mikulas Patocka <mpatocka@redhat.com>
To: Sami Tolvanen <samitolvanen@google.com>
Cc: Mike Snitzer <snitzer@redhat.com>, Milan Broz <mbroz@redhat.com>,
device-mapper development <dm-devel@redhat.com>,
Mandeep Baines <msb@chromium.org>, Will Drewry <wad@chromium.org>,
Kees Cook <keescook@chromium.org>,
linux-kernel@vger.kernel.org, Alasdair Kergon <agk@redhat.com>,
Mark Salyzyn <salyzyn@google.com>
Subject: Re: [PATCH 0/4] dm verity: add support for error correction
Date: Thu, 12 Nov 2015 13:50:04 -0500 (EST) [thread overview]
Message-ID: <alpine.LRH.2.02.1511121318110.15026@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <20151109191925.GA29185@google.com>
On Mon, 9 Nov 2015, Sami Tolvanen wrote:
> > Also, the 2 other big questions from Mikulas need answering:
> > 1) why aren't you actually adjustng error codes, returning success, if
> > dm-verity was able to trap/correct the corruption?
>
> We don't see actual I/O errors very often. Most corruption we've seen
> is caused by flaky hardware that doesn't return errors. However, I can
> certainly change to code to attempt recovery in this case too.
What flash controller and chips do you use? What is the probability of I/O
error and what is the probability of silent data corruption? Is the silent
data corruption permanent or transient? What is causing the silent data
corruption (decay in flash chips?, errors on the bus?) Why can't you ask
the hardware engineers to use a controler with proper error correction?
Without these data - it looks like you first wrote the patch and then
tried to make some excuses why it should be accepted.
I'm also a little bit concerned that the patch will increase prevalence of
crapware on the market - when accepted, this kind of reasoning will
follow: "now we have error correction in the kernel, so we cut down flash
overprovisioning, save a dollar or two per device, and produce a crap that
randomly corrupts user's data on the read-write partition (because that
partition not protected by the error correction)".
Mikulas
next prev parent reply other threads:[~2015-11-12 18:50 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 2:02 [PATCH 0/4] dm verity: add support for error correction Sami Tolvanen
2015-11-05 2:02 ` Sami Tolvanen
2015-11-05 2:02 ` [PATCH 1/4] dm verity: clean up duplicate hashing code Sami Tolvanen
2015-11-17 22:32 ` Kees Cook
2015-11-05 2:02 ` [PATCH 2/4] dm verity: separate function for parsing opt args Sami Tolvanen
2015-11-05 2:02 ` Sami Tolvanen
2015-11-17 22:33 ` Kees Cook
2015-12-02 20:16 ` Mike Snitzer
2015-11-05 2:02 ` [PATCH 3/4] dm verity: add support for forward error correction Sami Tolvanen
2015-11-05 5:36 ` kbuild test robot
2015-11-05 5:36 ` kbuild test robot
2015-11-05 22:06 ` kbuild test robot
2015-11-05 22:06 ` kbuild test robot
2015-11-05 2:02 ` [PATCH 4/4] dm verity: ignore zero blocks Sami Tolvanen
2015-11-05 22:13 ` kbuild test robot
2015-11-05 22:13 ` kbuild test robot
2015-11-05 7:34 ` [PATCH 0/4] dm verity: add support for error correction Milan Broz
2015-11-05 17:33 ` Sami Tolvanen
2015-11-09 16:37 ` Mike Snitzer
2015-11-09 19:19 ` Sami Tolvanen
2015-11-09 19:58 ` Mike Snitzer
2015-11-12 10:30 ` Milan Broz
2015-12-03 9:36 ` Sami Tolvanen
2015-11-12 18:50 ` Mikulas Patocka [this message]
2015-12-03 9:33 ` Sami Tolvanen
2015-12-02 20:22 ` Mike Snitzer
2015-12-03 9:11 ` Sami Tolvanen
2015-11-06 17:23 ` Mikulas Patocka
2015-11-06 19:06 ` Sami Tolvanen
2015-11-06 19:20 ` [dm-devel] " Zdenek Kabelac
2015-11-06 20:27 ` Sami Tolvanen
2015-11-06 21:05 ` Zdenek Kabelac
2015-11-06 21:23 ` Sami Tolvanen
2015-11-07 15:29 ` Mikulas Patocka
2015-11-07 15:20 ` Mikulas Patocka
2015-11-07 15:18 ` Mikulas Patocka
2015-11-09 15:06 ` Austin S Hemmelgarn
2015-12-03 14:26 ` [PATCH v2 0/2] " Sami Tolvanen
2015-12-03 14:26 ` [PATCH v2 1/2] dm verity: add support for forward " Sami Tolvanen
2015-12-03 14:26 ` [PATCH v2 2/2] dm verity: ignore zero blocks Sami Tolvanen
2015-12-03 19:54 ` [PATCH v2 0/2] dm verity: add support for error correction Mike Snitzer
2015-12-03 23:05 ` Mike Snitzer
2015-12-04 10:03 ` Sami Tolvanen
2015-12-04 21:09 ` Mike Snitzer
2015-12-07 13:21 ` Sami Tolvanen
2015-12-07 14:58 ` Mike Snitzer
2015-12-07 14:58 ` Mike Snitzer
2015-12-07 16:31 ` Sami Tolvanen
2015-12-07 18:07 ` Milan Broz
2015-12-07 19:07 ` Mike Snitzer
2015-12-08 10:18 ` Sami Tolvanen
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=alpine.LRH.2.02.1511121318110.15026@file01.intranet.prod.int.rdu2.redhat.com \
--to=mpatocka@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbroz@redhat.com \
--cc=msb@chromium.org \
--cc=salyzyn@google.com \
--cc=samitolvanen@google.com \
--cc=snitzer@redhat.com \
--cc=wad@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.