public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] request for ubifs recovery support
Date: Wed, 17 Nov 2010 17:25:53 +0100	[thread overview]
Message-ID: <4CE40211.3050000@free.fr> (raw)
In-Reply-To: <1290009710.8950.37.camel@dubciaranr0.verifone.com>

Le 17/11/2010 17:01, Quotient Remainder a ?crit :
> Ar Aoine, 2010-09-17 ag 12:44 -0400, scr?obh Eric Cooper:
>> But I just discovered that it has a fatal disadvantage.  My device
>> can't reboot when the ubifs is corrupted, which happened today after a
>> power failure:
>>
>>      UBIFS: recovery needed
>>      Error reading superblock on volume 'ubi:root'!
>>
>> Ubifs includes recovery code, but since u-boot treats it as a
>> read-only mount, this is never performed.  Once I booted Linux,
>> everything was fine.
>>
>> I'd like to request that the read-only flag be removed (at least to
>> allow recovery) so that the ubifs-only scheme can be used reliably.
>>
>
> Has this received any attention or is there an existing way to recover
> from these types of error?
>
> In devices I'm using, the problem is most apparent when the UBIFS RFS is
> mounted with "rootflags=sync" and a large file is copied into that RFS
> in Linux.  When the unit's power is cycled immediately on the "cp"
> command returning, the ubifsload command in U-Boot fails with the same
> error as mentioned by Eric Cooper above.

I don't know ubifs very well to say the least, but something strikes me 
in what you describe: ''the unit's power is cycled immediately on the 
"cp" command returning''.

Do you mean that, in Linux, you do a power cycle without (syncing and) 
unmounting a file system that will be critical to properly booting later 
on? If so, what is the rationale behind this too-quick power cycle?

Seems to me you should start by the preventive measure of avoiding the 
corruption in the first place (do a cp; sync; umount...) rather than 
relying on a curative measure of recovery attempts.

Amicalement,
-- 
Albert.

  reply	other threads:[~2010-11-17 16:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-17 16:44 [U-Boot] request for ubifs recovery support Eric Cooper
2010-11-17 16:01 ` Quotient Remainder
2010-11-17 16:25   ` Albert ARIBAUD [this message]
2010-11-17 18:01     ` Quotient Remainder
2010-11-17 18:13       ` Albert ARIBAUD
2010-11-19 11:03         ` Detlev Zundel

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=4CE40211.3050000@free.fr \
    --to=albert.aribaud@free.fr \
    --cc=u-boot@lists.denx.de \
    /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