From: Richard Weinberger <richard@nod.at>
To: Martin Townsend <mtownsend1973@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: UBIFS question
Date: Thu, 17 Mar 2016 12:25:48 +0100 [thread overview]
Message-ID: <56EA943C.4000505@nod.at> (raw)
In-Reply-To: <CABatt_xRMWwByY2nE8cpcjOL2jgt4yMhH9Gm4cWkxG_uhO7T5A@mail.gmail.com>
Martin,
Am 17.03.2016 um 12:16 schrieb Martin Townsend:
>>> 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.
>
> We expect the flash devices to start failing quicker than normally
> expected due to the environment in which they will be operating in, so
> sudden NAND blocks turning bad will eventually happen and what we
> would like to do is try and capture this as soon as possible.
> The boards are not accessible as they will be located in very remote
> locations so detecting these failures before the system locks up would
> be an advantage so we can report home with the information and fail
> over to the other filesystem (providing that hasn't also been
> corrupted).
Dealing with sudden bad NAND blocks is almost impossible.
Unless you have a copy of each block.
NAND is not expected to gain bad blocks without an indication like
correctable bitflips.
Thanks,
//richard
next prev parent reply other threads:[~2016-03-17 11:26 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
2016-03-17 11:16 ` Martin Townsend
2016-03-17 11:25 ` Richard Weinberger [this message]
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=56EA943C.4000505@nod.at \
--to=richard@nod.at \
--cc=linux-mtd@lists.infradead.org \
--cc=mtownsend1973@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 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.