From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vikram Narayanan Date: Wed, 31 Oct 2012 22:25:12 +0530 Subject: [U-Boot] UBIFS fails on SheevaPlug In-Reply-To: <509156C2.1070801@gmail.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> <5091518B.8050007@gmail.com> <509156C2.1070801@gmail.com> Message-ID: <509157F0.8000808@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/31/2012 10:20 PM, Andreas Bie?mann wrote: > Dear Vikram Narayanan, > > On 31.10.2012 17:27, Vikram Narayanan wrote: >> 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? > > I dunno cause he has an old version which do not print the error code > (patch f75325e1927398f7e18e15f186b1fc52174cc19f is missing). > >>> 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. > > Please read mount_ubifs() in fs/ubifs/super.c:582 > > Even if it is mounted read only and recovery is needed it will > ubifs_lpt_init(), ubifs_replay_journal(), ubifs_mount_orphans(), ... > If recovery is needed it will ubifs_recover_size() and if it is mounted > read only it will print at last 'recovery deferred' (in the other case > it would be still repaired here cause the steps before do it). > So at least a read only fs which needs recovery can be successfully > mounted (if no other error occurs; the most likely error is a ENOMEM > cause the ubifs does a lot of k(z)alloc). Thanks. I'll look at this. >>> 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). > > Well bootargs can have 'ro' so the root partition will be mounted read > only, wouldn't it? Wouldn't this 'ro' root partition not mounted by the > kernel then? Got your point here. Then no feature could be claimed as 'missing' in the u-boot's ubifs compared to the kernel's, except for the well known fact that u-boot's ubi layer is old code. Regards, Vikram