Problem mounting a UBIFS volume

[Adrian Hunter]

Adrian Hunter wrote:
> Bruce_Leonard at selinc.com wrote:
>> Artem,
>>
>> Sorry for the delay in replying, I was on holiday for a couple of weeks 
>> and it's taken me a while to get my brain wrapped back around what I was 
>> working on when I left :).
>>
>> Artem Bityutskiy <dedekind at infradead.org> wrote on 07/04/2008 06:02:29 AM:
>>
>>> On Wed, 2008-07-02 at 22:18 -0700, Bruce_Leonard at selinc.com wrote:
>>>> UBIFS error (pid 842): check_lpt_crc:invalid crc in LPT node: crc 2bbb 
>>>> calc a5a5
>>>> UBIFS error (pid 842): ubifs_read_nnode: error -22 reading nnode at 
>> 8:6150
>>>> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
>>>>        missing codepage or other error
>>>>        In some cases useful info is found in syslog - try
>>>>        dmesg | tail  or so
>>> AFAIU, you still use a small flash and small image. So the only change
>>> was your MTD change. Are you sure it is not the MTD change which is to
>>> blame? Can you reproduce this error without your MTD change?
>>>
>> Yes I can and here's what I've found.  I pulled the latest vanilla kernel 
>> from Linus' tree (congratulations on getting UBIFS in BTW, very cool), 
>> pulled the latest mkfs.ubifs, and did an entirely new clone of mtd-utils 
>> (I wanted to get rid of my modifications).  So there are NONE of my MTD 
>> changes in any of the code I'm currently using.  I also reset my driver to 
>> only recognize 2GiB of NAND.  Before I left I was starting to get 
>> suspicious of mkfs.ubifs, so I ran the following experiment this morning. 
>> I used mkfs.ubifs to create two different images of the same filesystem 
>> (one for up to 2GiB devices and one for up to 8GiB devices) as follows:
>>
>> $ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 16384 -o x103.img
>> $ mkfs.ubifs -r x103/ -m 2048 -e 129024 -c 65536 -o x103_large.img
>>
>> If I understand things right (which usually isn't the case :-\), these 
>> should be more or less the same, because the -c option is just specifying 
>> a MAXIMUM volume size the image can be put onto.  An ls -l command gives 
>> the following:
>>
>> -rw-r--r--  1 root root  29159424 Jul 23 13:31 x103.img
>> -rw-r--r--  1 root root  30449664 Jul 23 14:08 x103_large.img
>>
>> So they match pretty close in size.  I can burn both images to my NAND 
>> without errors by:
>>
>> $ ubiupdatevol /dev/ubi0_0 x103*.img
>>
>> When I try to mount the filesystem that comes from x103.img (the one for 
>> the 'smaller' NAND flash) it mounts just fine, I can cd to it, create 
>> directories/files, etc.  However, when I try to mount the filesystem from 
>> x103_large.img, it fails with the following errors:
>>
>> UBIFS error (pid 863): check_lpt_crc: invalid crc in LPT node: crc f486 
>> calc e0b
>> UBIFS error (pid 863): ubifs_read_nnode: error -22 reading nnode at 8:1356
>>
>> mount: wrong fs type, bad option, bad superblock on ubi0:bob,
>>        missing codepage or other error
>>        In some cases useful info is found in syslog - try
>>        dmesg | tail  or so
>>
>> So, here's a couple of questions?  Does mkfs.ubifs and UBIFS calculate the 
>> CRC identically or could there be a difference that's causing the problem? 
>>  Does ubiupdatevol touch the CRC and that's what's causing the problem?  A 
>> complicating factor, I'm running on an MPC8349E, which is big endian and I 
>> know we've tripped across an endian issue in the past.  I've tried 
>> eliminating endian issues by compiling and running all tools native on the 
>> 8347, but could that be a factor?
>>
>> I'm going to start by digging into mkfs.ubifs on the assumption that the 
>> large -c parameter is causing it to some how miscalculate the CRC, but any 
>> pointers of where else the problem could be are greatly appreciated.
> 
> Almost certainly mkfs.ubifs has screwed up the LPT.  That is because the
> LPT is a tree that is sized according to the maximum size that the file system
> can grow to i.e. the size given by the -c option
> 
> I will look at this.

I tried this with a 2GiB nandsim and did not get any problems.

Are you able to make available an image that I can test?  Obviously if you are
able to make a small image that has the problem it would be easier to handle.