From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vikram Narayanan Date: Wed, 31 Oct 2012 21:57:55 +0530 Subject: [U-Boot] UBIFS fails on SheevaPlug In-Reply-To: <508F0AED.9030108@googlemail.com> References: <201210282354.02300.marex@denx.de> <508E26D3.5030606@googlemail.com> <508E409B.20501@gmail.com> <508E4829.90004@gmail.com> <508ED095.4080502@gmail.com> <508F0AED.9030108@googlemail.com> Message-ID: <5091518B.8050007@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Andreas, On 10/30/2012 4:32 AM, Andreas Bie?mann wrote: > Dear Vikram Narayanan, > > first of all you are right. u-boot ubifs implementation will never > recover the ubifs on media, cause it is mounted read only. > > calls sget() (line 1043) > which in turn calls kzalloc() (line 67) > which may return -ENOMEM I agree. But in Dimax's case this isn't. Right? > But u-boot will manage to get the data out of the unordered ubifs (if no > error like this ENOMEM occur). That is the same process as in kernel if > it is mounted read-only (recovery deferred). I can't comment on this, unless I know the specifics. > So if the kernel can manage to mount the unordered ubifs u-boot should > do so. If it can't (but the kernel can) there is an error that should be > fixed. > But in the kernel, the read-only isn't hardcoded. So, the kernel code can try to recover and even update the corrupted data back to the media and mount it. (It's my guess. The kernel may/mayn't do this way). But if the same fails to happen in u-boot code, I'd say the feature is missing and it needs to be pulled in from the kernel code. Regards, Vikram