From: Richard Weinberger <richard@nod.at>
To: Guilherme de Oliveira Costa <guilherme.oliveira@autotrac.com.br>,
"dedekind1@gmail.com" <dedekind1@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Filesystems over UBI can't handle badblocks
Date: Mon, 29 Feb 2016 20:06:38 +0100 [thread overview]
Message-ID: <56D496BE.9020908@nod.at> (raw)
In-Reply-To: <7F9DB42F7DDA544EA3EB31D694929A30EB9762@PERU.autotrac.corp>
Am 29.02.2016 um 18:53 schrieb Guilherme de Oliveira Costa:
>> I guess the reporter would come up with a good justification.
>>
>> I can imagine one, but it is not very strong: you have a development
>> device, you mess with bad blocks by marking/unmarking them for some
>> research reasons. You put UBI image there, then remember that some
>> of the blocks were bad and want to mark them as bad without re-
>> flashing UBI. Kind of a developer convenience.
>
> Indeed. Originally, we were using cramfs over mtdblock, but were running on all sorts of problems during testing due to random corruptions. I wanted to mess with the partition blocks to check how cramfs over UBI would handle badblocks and bit-errors.
What you can do is mounting debugfs and set /sys/kernel/debug/ubi/ubi<NUM>/tst_emulate_bitflips to 1.
Thanks,
//richard
next parent reply other threads:[~2016-02-29 19:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7F9DB42F7DDA544EA3EB31D694929A30EB9762@PERU.autotrac.corp>
2016-02-29 19:06 ` Richard Weinberger [this message]
2016-02-24 20:08 Filesystems over UBI can't handle badblocks Guilherme de Oliveira Costa
2016-02-24 21:30 ` Richard Weinberger
2016-02-25 9:02 ` Ricard Wanderlof
2016-02-25 10:49 ` Artem Bityutskiy
2016-02-25 21:10 ` Richard Weinberger
2016-02-26 8:24 ` 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=56D496BE.9020908@nod.at \
--to=richard@nod.at \
--cc=dedekind1@gmail.com \
--cc=guilherme.oliveira@autotrac.com.br \
--cc=linux-mtd@lists.infradead.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.