From: Artem Bityutskiy <dedekind1@gmail.com>
To: Daniel Kuhn <cheeef@swissonline.ch>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBIFS recovery fails
Date: Mon, 17 Oct 2011 23:17:48 +0300 [thread overview]
Message-ID: <1318882668.2172.10.camel@koala> (raw)
In-Reply-To: <4E9C2DAC.7090109@swissonline.ch>
On Mon, 2011-10-17 at 15:29 +0200, Daniel Kuhn wrote:
> Hi,
>
> I have a problem with a device which uses UBI + UBIFS on a 32GB NAND
> Flash (16*2GB). The
> filesystem worked without problems for a couple of months but now I get
> an error if I try to mount the volume.
> Attaching the UBI-Device works fine as you can see in the following
> messages:
This issue looks like one of the MLC-specific ones. Unfortunately,
no one really invested time into making UBIFS support MLC very well.
It needs some more work. It also have some issues related to unstable
bits in modern SLC.
In short - if you want to use UBIFS on MLC - you should not have unclean
reboots. If you want to make UBIFS 100% uclean-reboot save on MLC - you
need to work on it some more.
We (the original authors) developed and tested it on very robust SLC
NAND.
Unfortunately, I do not work with MTD for few years already and have
no spare time to make it MLC-robust. My last attempt was this spring -
I started making integck test (in mtd-utils) support emulated power
cuts. The idea was to improve UBIFS power-cut emulation infrastructure
and make it emulating unstable bits, and then test and fix all issues.
But then I realized that I simply will not have time to finish it,
so left the work half-done.
If someone wants to see UBIFS 100% or near 100% power-cut safe on
MLC or one of shitty modern SLCs - he needs to invest men-hours.
I can help by suggesting and reviewing. Although the funny thing is
that eMMCs die and lose data in case of power cuts very often :-)
> UBI: wear-leveling threshold: 4096
Are you sure it is good for MLC? What is your eraseblock life-cycle?
> Is there a way to recover the data on the device?
If you just have precious data which you need - I think:
1. Make a dump of the flash.
2. Verify that on another device you can flash it and reproduce this
issue.
3. Just hack the function in kernel that fails to return 0 instead
of error for that case, and I think you will be able to mount your
flash and copy your data.
But if you want this to never happen again - you need to prepare
for a several months project (providing you have a good kernel
engineer).
HTH :-)
next prev parent reply other threads:[~2011-10-17 20:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 13:29 UBIFS recovery fails Daniel Kuhn
2011-10-17 20:17 ` Artem Bityutskiy [this message]
2011-10-18 8:11 ` Ricard Wanderlof
2011-10-18 8:42 ` Ivan Djelic
2011-10-20 16:37 ` Artem Bityutskiy
2011-10-20 16:36 ` Artem Bityutskiy
2011-10-18 8:29 ` Ivan Djelic
2011-10-19 15:15 ` Artem Bityutskiy
2011-10-19 17:27 ` Ivan Djelic
2011-10-18 12:47 ` Jean-Sébastien Gagnon
2011-10-18 14:54 ` Ivan Djelic
2011-10-18 15:10 ` Jean-Sébastien Gagnon
2011-10-18 15:32 ` Ivan Djelic
2011-10-18 16:05 ` Jean-Sébastien Gagnon
2011-10-19 6:50 ` Ricard Wanderlof
2011-10-19 10:22 ` Ivan Djelic
2011-10-19 12:17 ` Atlant Schmidt
2011-10-19 12:52 ` Ricard Wanderlof
2011-10-19 13:30 ` Atlant Schmidt
2011-10-20 16:43 ` Artem Bityutskiy
2011-10-24 7:00 ` Ricard Wanderlof
2011-10-29 19:43 ` Artem Bityutskiy
2011-10-20 14:14 ` Artem Bityutskiy
2011-10-18 15:29 ` Daniel Kuhn
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=1318882668.2172.10.camel@koala \
--to=dedekind1@gmail.com \
--cc=cheeef@swissonline.ch \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).