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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox