Expanding UBI fs to maxavailable size

Expanding UBI fs to maxavailable size

[Karsten Jeppesen]

Hi there,
....I think I found an error :-)

I have an ARM platform with either 32 or 64MB FLASH, and I want to make 
an image that I can burn more or less directly (ie: not tar) into the 
flash regardless if its the 32 or the 64MB edition.
So I assumed that is what the autoresize flag is about, but maybe I am 
wrong here.
I can get ubiformat to burn the image to the flash, but subsequently the 
filesystem doesn't expand to occupy the max available area.
What am I doing wrong - and how is it supposed to be achieved? Or is 
this an error or a missing feature?

Content of ubinize.cfg is>
---
[kjp_ubi]
mode=ubi
image=kjp.img
vol_id=0
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
---

and my generation script looks like this:
---
#!/bin/sh
rm -rf work *.img 2>/dev/null
mkdir work
tar xzf armroot-stripped.tar.gz --directory work
mkfs.ubifs --root=work --min-io-size=1 --leb-size=130944 
--max-leb-cnt=232 -o kjp.img -x zlib
ubinize -o ubi.img --min-io-size=1 --peb-size=131072 ubinize.cfg
---

Burning the image to flash using:
ubiformat /dev/mtd4 -e 0 --yes -f ubi.img

The resulting filesystem will in the 64 MB edition be about 470 leb's. 
But the stupid thing wont expand. Sigh.

Enlightenment will be greatly appreciated

Sincerely,
Karsten Jeppesen

Re: Expanding UBI fs to maxavailable size

[Artem Bityutskiy]

On Mon, 2010-10-18 at 23:22 +0200, Karsten Jeppesen wrote:
> Hi there,
> ....I think I found an error :-)
> 
> I have an ARM platform with either 32 or 64MB FLASH, and I want to make 
> an image that I can burn more or less directly (ie: not tar) into the 
> flash regardless if its the 32 or the 64MB edition.
> So I assumed that is what the autoresize flag is about, but maybe I am 
> wrong here.
> I can get ubiformat to burn the image to the flash, but subsequently the 
> filesystem doesn't expand to occupy the max available area.
> What am I doing wrong - and how is it supposed to be achieved? Or is 
> this an error or a missing feature?

What do you see in dmesg from UBI/UBIFS?

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

Re: Expanding UBI fs to maxavailable size

[Karsten Jeppesen]

Hi Artem,

This is Karsten Jeppesen, just using an out-of-the-house account,
and thanks for your very quick reply.

The short answer to your question about dmesg is: no messages at any point from 
UBI whatsoever.

Here is a more detailed answer:
This part is executed on the development machine which is a Fedora running on an 
x86:
[root@vserver09 ubifs]# rm -rf work *.img 2>/dev/null
[root@vserver09 ubifs]# mkdir work
[root@vserver09 ubifs]# tar xzf /tftpboot/SKOV/armroot-stripped.tar.gz 
--directory work
[root@vserver09 ubifs]# mkfs.ubifs --root=work --min-io-size=1 --leb-size=130944 
--max-leb-cnt=232 -o kjp.img -x zlib
[root@vserver09 ubifs]# ubinize -o ubi.img --min-io-size=1 --peb-size=131072 
ubinize.cfg
ubinize: volume size was not specified in section "kjp_ubi", assume minimum to 
fit image "kjp.img"14272896 bytes (13.6 MiB)

Content of ubinize.cfg is:
[kjp_ubi]
mode=ubi
image=kjp.img
vol_id=0
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize

Next part is executed on the target ARM 9263 with the 64MB FLASH fitted, running 
my distribution (Fedora based) via NFS (so the FLASH is not used)
Logging rerouted to console so it intermixes commands:
ubiformat: mtd4 (nor), size 63700992 bytes (60.8 MiB), 486 eraseblocks of 131072 
bytes (128.0 KiB), min. I/O size 1 bytes
libscan: scanning eraseblock 485 -- 100 % complete
ubiformat: 485 eraseblocks have valid erase counter, mean value is 0
ubiformat: 1 eraseblocks are supposedly empty
ubiformat: use erase counter 0 for all eraseblocks
ubiformat: flashing eraseblock 110 -- 100 % complete
ubiformat: formatting eraseblock 485 -- 100 % complete
# ubiattach /dev/ubi_ctrl -m 4
UBI device number 0, total 486 LEBs (63638784 bytes, 60.7 MiB), available 0 LEBs 
(0 bytes), LEB size 130944 bytes (127.9 KiB)
# mkdir -p /skov/mnt/ubi
# mount -t ubifs ubi0:rootfs /skov/mnt/ubi

As of this point no messages has been received via syslog from the UBI system

Here comes what I don't like. Meaning that I can see the rationale, but its not 
what I hoped for:
Ubinfo shows that ubiformat correctly

# ubinfo -a
UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:63
Present UBI devices:            ubi0

ubi0
Volumes count:                           1
Logical eraseblock size:                 130944 bytes, 127.9 KiB
Total amount of logical eraseblocks:     486 (63638784 bytes, 60.7 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  0
Current maximum erase counter value:     1
Minimum input/output unit size:          1 byte
Character device major/minor:            251:0
Present volumes:                         0

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        482 LEBs (63115008 bytes, 60.2 MiB)
State:       OK
Name:        rootfs
Character device major/minor: 251:1

But df reveils that the rootfs partition still is only 25MB where I had surely 
hoped for near 64MB
# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root               120.9G     43.8G     75.9G  37% /
none                     61.3M         0     61.3M   0% /dev
none                     61.3M    116.0K     61.2M   0% /var/run
/skov/dev/sdcard1         1.8G     34.9M      1.7G   2% /skov/mnt/data
ubi0:rootfs              25.0M     11.7M     13.3M  47% /skov/mnt/ubi

It seems like the autoresize flag says: OK - you made a 25MB partition and I 
packed this down at 13MB and now I will autoresize it to 25MB again. O - so you 
have 64MB - Cool then you have additional useless empty space.

I am looking for: Ok - so I packed your partition to 13MB and format now shows 
me full 64 MB. I will autoresize to the 64MB.









----- Original Message ----
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Karsten Jeppesen <karsten@jeppesens.com>
Cc: linux-mtd@lists.infradead.org
Sent: Tue, October 19, 2010 7:12:34 AM
Subject: Re: Expanding UBI fs to maxavailable size

On Mon, 2010-10-18 at 23:22 +0200, Karsten Jeppesen wrote:
> Hi there,
> ....I think I found an error :-)
> 
> I have an ARM platform with either 32 or 64MB FLASH, and I want to make 
> an image that I can burn more or less directly (ie: not tar) into the 
> flash regardless if its the 32 or the 64MB edition.
> So I assumed that is what the autoresize flag is about, but maybe I am 
> wrong here.
> I can get ubiformat to burn the image to the flash, but subsequently the 
> filesystem doesn't expand to occupy the max available area.
> What am I doing wrong - and how is it supposed to be achieved? Or is 
> this an error or a missing feature?

What do you see in dmesg from UBI/UBIFS?

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


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/



    

Re: Expanding UBI fs to maxavailable size

[Artem Bityutskiy]

On Tue, 2010-10-19 at 01:17 -0700, Karsten Jeppesen wrote:
> Hi Artem,
> 
> This is Karsten Jeppesen, just using an out-of-the-house account,
> and thanks for your very quick reply.

UBI and UBIFS always print something, refer:
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_how_send_bugreport
item 3.

Anyway, AFAICS, UBI auto-resize the UBI volume correctly, because of
this:

> ubi0
> Volumes count:                           1
> Logical eraseblock size:                 130944 bytes, 127.9 KiB
> Total amount of logical eraseblocks:     486 (63638784 bytes, 60.7 MiB)

I re-sized.

However, UBIFS file-system did not re-size, because you specified too
small maximum UBIFS LEB count: --max-leb-cnt=232

Try --max-leb-cnt=511 and it should work. Take a look here:
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_max_leb_cnt

I agree this all stuff is not as user-friendly as it could, but you have
a good chance to make it user-friendlier by contributing docs or code.

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