[U-Boot] request for ubifs recovery support

[U-Boot] request for ubifs recovery support

[Eric Cooper]

I've configured my device (a Seagate DockStar) with just two NAND
flash partitions -- one for u-boot and one for the Linux rootfs.

This has some nice advantages: it maximizes the available flash space,
and allows the Linux distribution's own tools to install new kernel
and initramfs files without having to know about flash partitions.

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.

-- 
Eric Cooper             e c c @ c m u . e d u

[U-Boot] request for ubifs recovery support

[Quotient Remainder]

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.

[U-Boot] request for ubifs recovery support

[Albert ARIBAUD]

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.

[U-Boot] request for ubifs recovery support

[Quotient Remainder]

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.

[U-Boot] request for ubifs recovery support

[Albert ARIBAUD]

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.

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.

Amicalement,
-- 
Albert.

[U-Boot] request for ubifs recovery support

[Detlev Zundel]

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