Re: [U-Boot] request for ubifs recovery support
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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] request for ubifs recovery support
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] request for ubifs recovery support
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] request for ubifs recovery support
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] request for ubifs recovery support
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
