bud_replay size question

bud_replay size question

[Steve Iribarne]

Hi List.

We had a problem here in our released product where we would get the 
dreaded "Error reading superblock!".

First some stats:

ARM processor (iMX25)
U-Boot version (U-Boot 2009.06-rc2-svn3608)  <- I know this is 
autogenerated but what the heck...

I still don't know how to reproduce the problem but I know what is 
causing the issue.

The issue is that ubifs_get_sb fails.  The reason it fails is that 
insert_node (u-boot/fs/ubifs/replay.c) runs out of memory.  So I can fix 
the problem by giving u-boot more space for malloc (increase the size of 
CONFIG_SYS_MALLOC_LEN)

This is all fine and dandy but I really don't like updating the bootrom 
in the field.  So I'm trying to get this value correct.

I have approx. 58MB to play with here.

Our file system lives on a NAND flash that is 256MB total but I have it 
broken up into 3 partitions.
1 is 10MiB and the other two (the ones that really hold most of the 
data) have 100MiB each.

What I'm trying to determine is how to figure out how big the replay_bud 
LEB list can get based on my configuration.  Is there such a thing or am 
I just dreaming?

Thanks.
-stv

-- 
Steve Iribarne
Sr. Software Engineer
Embedded Devices

Re: bud_replay size question

[Artem Bityutskiy]

On Wed, 2010-12-01 at 10:20 -0800, Steve Iribarne wrote:
> What I'm trying to determine is how to figure out how big the replay_bud 
> LEB list can get based on my configuration.  Is there such a thing or am 
> I just dreaming?

Yeah, maximum amount of buds is max_bud_bytes / leb_size rounded up, I
thing. max_bud_bytes is stored in the superblock (see struct
ubifs_sb_node). The smaller it is, the smaller is the UBIFS journal.

You can control max_bud_bytes with the -j option of mkfs.ubifs. Try to
make it smaller.

Frankly, we (UBIFS authors) made this mechanism, but never really played
with journal size and always used the default one. Please, play with
this and report your findings - you can hit bugs if you start making it
too small or too large, but may be not. Dunno. But it has to make UBIFS
keep the journal smaller.

Alternatively, you can try to look at all UBIFS allocations. I will not
be surprized if it allocates some buffers which are not really neaded in
R/O mode, although we did do some work to allocate less resources when
we are in R/O mode. You can experiment in Linux, because it is easier,
and if you find unneeded buffers, fix this, and then port your changes
to u-boot.

HTH.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: bud_replay size question

[Artem Bityutskiy]

On Fri, 2010-12-03 at 18:07 +0200, Artem Bityutskiy wrote:
> Alternatively, you can try to look at all UBIFS allocations. I will not
> be surprized if it allocates some buffers which are not really neaded in
> R/O mode, although we did do some work to allocate less resources when
> we are in R/O mode. You can experiment in Linux, because it is easier,
> and if you find unneeded buffers, fix this, and then port your changes
> to u-boot.

And you can try to look at UBI - in R/O mode we probably need less than
we allocate, but again dunno for sure, should be checke.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: bud_replay size question

[Steve Iribarne]

Artem Bityutskiy wrote:
> On Fri, 2010-12-03 at 18:07 +0200, Artem Bityutskiy wrote:
>> Alternatively, you can try to look at all UBIFS allocations. I will not
>> be surprized if it allocates some buffers which are not really neaded in
>> R/O mode, although we did do some work to allocate less resources when
>> we are in R/O mode. You can experiment in Linux, because it is easier,
>> and if you find unneeded buffers, fix this, and then port your changes
>> to u-boot.
> 
> And you can try to look at UBI - in R/O mode we probably need less than
> we allocate, but again dunno for sure, should be checke.
> 
Once I get this release out the door I will play around with this and 
report back.

-stv

-- 
Steve Iribarne
Sr. Software Engineer
Embedded Devices