From: Richard Weinberger <richard@nod.at>
To: Martin Townsend <mtownsend1973@gmail.com>,
Richard Weinberger <richard.weinberger@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: UBIFS question
Date: Thu, 17 Mar 2016 09:56:40 +0100 [thread overview]
Message-ID: <56EA7148.7050008@nod.at> (raw)
In-Reply-To: <CABatt_w_hXqUA45-MzU3_DRox0P9CwraTCY_TYPthdA3O0N-eQ@mail.gmail.com>
Martin,
Am 17.03.2016 um 09:33 schrieb Martin Townsend:
> Hi Richard,
>
> Thanks for the reply. rsync is the backup plan, I just wanted to rule
> other options out first. The flash devices are going to subjected to a
> fairly harsh environment and the idea of being able to fail over to a
> backup docker container was appealing.
>
> Which leads me to a couple of questions:
> 1) I need to simulate flash devices reading corrupted
> pages/blocks/LEBs. Is there currently a way of doing this? if not
> would it be possible to write something, say a kernel module to sit
> above the NAND driver to do this. I just want to see what effect
> corruption has on a live system and how these errors manifest
> themselves.
check out nandsim and UBI's debugfs. We have a lot of knobs to
simulate such stuff.
> 2) One thing I'm going to have to do is write a background thread to
> monitor the status of the filesystem and try and detect corruption
> before the system becomes unstable, is there any way to find out the
> validity of the LEBs, ie checking their checksums.
So, what exactly is the error scenario you have in mind?
If the SLC NAND behaves correctly UBIFS can deal with all kinds
of errors.
Of course UBI (and UBIFS) is not a magic bullet, if a NAND block
turns bad all of a sudden there is nothing it can do for you.
But this NAND would also not be with in the spec...
It is not clear do me what this background thread should achieve.
Thanks,
//richard
next prev parent reply other threads:[~2016-03-17 8:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-16 9:54 UBIFS question Martin Townsend
2016-03-16 23:12 ` Richard Weinberger
2016-03-17 8:33 ` Martin Townsend
2016-03-17 8:56 ` Richard Weinberger [this message]
2016-03-17 11:16 ` Martin Townsend
2016-03-17 11:25 ` Richard Weinberger
2016-03-17 11:43 ` Ricard Wanderlof
2016-03-17 12:54 ` Martin Townsend
2016-03-17 14:55 ` Boris Brezillon
2016-03-17 15:39 ` Martin Townsend
2016-03-17 15:59 ` Richard Weinberger
-- strict thread matches above, loose matches on Subject: below --
2009-07-10 18:43 UBIFS Question Laurent .
2009-07-10 20:01 ` Corentin Chary
2009-07-11 14:55 ` Artem Bityutskiy
2009-07-14 6:11 ` Laurent .
2009-07-14 7:22 ` Artem Bityutskiy
2009-07-11 15:54 ` Vitaly Wool
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=56EA7148.7050008@nod.at \
--to=richard@nod.at \
--cc=linux-mtd@lists.infradead.org \
--cc=mtownsend1973@gmail.com \
--cc=richard.weinberger@gmail.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