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