From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] request for ubifs recovery support
Date: Fri, 19 Nov 2010 12:03:30 +0100 [thread overview]
Message-ID: <m2zkt5r2wt.fsf@ohwell.denx.de> (raw)
In-Reply-To: <4CE41B2F.1010709@free.fr> (Albert ARIBAUD's message of "Wed, 17 Nov 2010 19:13:03 +0100")
Hi Albert,
> Le 17/11/2010 19:01, Quotient Remainder a ?crit :
>> Ar C?ad, 2010-11-17 ag 17:25 +0100, scr?obh Albert ARIBAUD:
>>
>>> 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?
>>
>> Yes, I'm testing power-fail tolerance! The RFS is mounted in sync mode
>> so unless I'm missing something the sync should have occurred before the
>> command prompt reappears, right?
>>
>>>
>>> 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.
>>
>> Ideally, yes and "sync" before power-down works but that's not what
>> these tests are checking. With the RFS not in sync mode, it works;
>> "sync" command with sync mount currently untested.
>
>
> Ok, now I understand why you do this cp-then-powercycle routine.
>
> Granted, cp on a sync mount should have finished when you get back to
> the prompt, so that's one Linux, not U-boot, issue to dig into; but
> anyway, if you're testing for powerfail conditions, I guess you also
> test power-cycling in the middle of the cp, so you may end up with a
> corrupted ubifs anyway.
Exactly.
> I guess if you or Eric know how to enable ubifs recovery in u-boot, the
> simplest course of action is to just go ahead and try it -- but I still
> think the cp+powercycle issue is caused purely in Linux and should be
> fixed there.
If we use UBIFS in U-Boot then we need to be prepared for whatever state
the UBIFS is in on powerup. Tolerance to power failures is one of the
topmost featues of this fs (number 4 according to its webpage :) so
U-Boot not having this property feels like a let down.
Actually I wonder why nobody complained earlier about that...
Cheers
Detlev
--
Man against god... God against Man... Man against nature... Nature against
man... God against nature... Nature against god... a very, very funny
religion. -- Zen Master D.T. Suzuki commenting on Christianity
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
prev parent reply other threads:[~2010-11-19 11:03 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
2010-11-17 18:01 ` Quotient Remainder
2010-11-17 18:13 ` Albert ARIBAUD
2010-11-19 11:03 ` Detlev Zundel [this message]
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=m2zkt5r2wt.fsf@ohwell.denx.de \
--to=dzu@denx.de \
--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 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.