From: Pavel Machek <pavel@ucw.cz>
To: Richard Weinberger <richard@nod.at>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
cyrille.pitchen@wedev4u.fr, marek.vasut@gmail.com,
boris.brezillon@free-electrons.com, computersforpeace@gmail.com,
dwmw2@infradead.org, dedekind1@gmail.com, tharvey@gateworks.com,
stable@vger.kernel.org
Subject: Re: [PATCH] ubi: Reject MLC NAND
Date: Wed, 7 Mar 2018 00:18:05 +0100 [thread overview]
Message-ID: <20180306231805.GA28183@amd> (raw)
In-Reply-To: <20180303104554.5958-1-richard@nod.at>
[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]
On Sat 2018-03-03 11:45:54, Richard Weinberger wrote:
> While UBI and UBIFS seem to work at first sight with MLC NAND, you will
> most likely lose all your data upon a power-cut or due to read/write
> disturb.
> In order to protect users from bad surprises, refuse to attach to MLC
> NAND.
>
> Cc: stable@vger.kernel.org
That sounds like _really_ bad idea for stable. All it does is it
removes support for hardware that somehow works.
Now... Yes, handling flash is hard, MLC NAND is worst of the
bunch. But...
Read disturb is not unique to MLC, right? Happens to all the flashes,
its just that MLC has tighter margins for error.
Power-cut. UBIFS is just not power-cut safe, right? My notes say that
power-cut during erase could result in flash that contains all 1s, but
will start showing errors very quickly. Again, not MLC specific. Can
be solved with battery...
(And yes, there are some problems specific to MLC, where parts of page
need to be written in specific order. Not sure how it affects
ubifs. But it was not listed as a reason for the patch.)
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
> drivers/mtd/ubi/build.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
> index e941395de3ae..753494e042d5 100644
> --- a/drivers/mtd/ubi/build.c
> +++ b/drivers/mtd/ubi/build.c
> @@ -854,6 +854,17 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num,
> return -EINVAL;
> }
>
> + /*
> + * Both UBI and UBIFS have been designed for SLC NAND and NOR flashes.
> + * MLC NAND is different and needs special care, otherwise UBI or UBIFS
> + * will die soon and you will lose all your data.
> + */
> + if (mtd->type == MTD_MLCNANDFLASH) {
> + pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n",
> + mtd->index);
> + return -EINVAL;
> + }
> +
> if (ubi_num == UBI_DEV_NUM_AUTO) {
> /* Search for an empty slot in the @ubi_devices array */
> for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2018-03-06 23:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-03 10:45 [PATCH] ubi: Reject MLC NAND Richard Weinberger
2018-03-04 19:46 ` Boris Brezillon
2018-03-06 23:18 ` Pavel Machek [this message]
2018-03-07 1:57 ` David Oberhollenzer
2018-03-07 8:01 ` Richard Weinberger
2018-03-07 15:24 ` Artem Bityutskiy
2018-03-07 21:43 ` Pavel Machek
2018-03-07 22:08 ` Steve deRosier
2018-03-07 22:11 ` David Woodhouse
2018-03-07 22:17 ` Pavel Machek
2018-03-07 22:30 ` Boris Brezillon
2018-03-07 23:27 ` Willy Tarreau
2018-03-07 22:40 ` Boris Brezillon
2018-03-08 13:42 ` Linus Walleij
2018-03-08 14:43 ` Richard Weinberger
2018-03-08 15:01 ` Artem Bityutskiy
2018-03-08 15:28 ` Richard Weinberger
2018-03-08 15:34 ` Artem Bityutskiy
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=20180306231805.GA28183@amd \
--to=pavel@ucw.cz \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
--cc=tharvey@gateworks.com \
/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