[U-Boot] request for ubifs recovery support
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.
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.
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,
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.
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,
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
participants (4)
-
Albert ARIBAUD -
Detlev Zundel -
Eric Cooper -
Quotient Remainder