2 replies to this topic

[Pedro_Newbie]

Is it possible to accurately determine the MKFS_UBIFS_ARGS values of a running system?
I want to read out some values to accurately determine the values used/to be used with MKFS.UBIFS nand UBINIZE.
The most values are no problem but the -c parameter of MKFS.UBIFS (-c, --max-leb-cnt=COUNT -> maximum logical erase block count) is puzzling me a bit
The mtdinfo -u of mtd0 (rootfs) is returning the following output

root@vusolo2:~# mtdinfo -u /dev/mtd0                               
mtd0                                                               
Name:                           rootfs                             
Type:                           nand                               
Eraseblock size:                131072 bytes, 128.0 KiB            
Amount of eraseblocks:          1800 (235929600 bytes, 225.0 MiB)  
Minimum input/output unit size: 2048 bytes                         
Sub-page size:                  2048 bytes                         
OOB size:                       64 bytes                           
Character device major/minor:   90:0                               
Bad blocks are allowed:         true                               
Device is writable:             true                               
Default UBI VID header offset:  2048                               
Default UBI data offset:        4096                               
Default UBI LEB size:           126976 bytes, 124.0 KiB            
Maximum UBI volumes count:      128                                

root@vusolo2:~#

 
I was expecting/hoping  to find the right value of 4096 for maximum logical erase block count, but I think the equivalent is Amount of eraseblocks: 1800, so no 4096

The

-m, --min-io-size=SIZE   minimum I/O unit size 
-e, --leb-size=SIZE      logical erase block size

parameters are -m 2048 -e 126976 but the -c parameter can't be determined (by me?)

Is there a way to accurate pinpoint the right value?

Part of the log from /var/log/messages*:

user.notice kernel: UBI: attaching mtd0 to ubi0
user.notice kernel: UBI: physical eraseblock size:   131072 bytes (128 KiB)
user.notice kernel: UBI: logical eraseblock size:    126976 bytes
user.notice kernel: UBI: smallest flash I/O unit:    2048
user.notice kernel: UBI: VID header offset:          2048 (aligned 2048)
user.notice kernel: UBI: data offset:                4096
user.notice kernel: UBI: max. sequence number:       1550
user.notice kernel: UBI: attached mtd0 to ubi0
user.notice kernel: UBI: MTD device name:            "rootfs"
user.notice kernel: UBI: MTD device size:            225 MiB
user.notice kernel: UBI: number of good PEBs:        1793
user.notice kernel: UBI: number of bad PEBs:         7
user.notice kernel: UBI: number of corrupted PEBs:   0
user.notice kernel: UBI: max. allowed volumes:       128
user.notice kernel: UBI: wear-leveling threshold:    4096
user.notice kernel: UBI: number of internal volumes: 1
user.notice kernel: UBI: number of user volumes:     1
user.notice kernel: UBI: available PEBs:             0
user.notice kernel: UBI: total number of reserved PEBs: 1793
user.notice kernel: UBI: number of PEBs reserved for bad PEB handling: 17
user.notice kernel: UBI: max/mean erase counter: 262/172
user.notice kernel: UBI: image sequence number:  673753318
user.notice kernel: UBI: background thread "ubi_bgt0d" started, PID 44
user.notice kernel: UBIFS: parse sync
user.notice kernel: UBIFS: mounted UBI device 0, volume 0, name "rootfs"
user.notice kernel: UBIFS: file system size:   223604736 bytes (218364 KiB, 213 MiB, 1761 LEBs)
user.notice kernel: UBIFS: journal size:       9023488 bytes (8812 KiB, 8 MiB, 72 LEBs)
user.notice kernel: UBIFS: media format:       w4/r0 (latest is w4/r0)
user.notice kernel: UBIFS: default compressor: lzo
user.notice kernel: UBIFS: reserved for root:  0 bytes (0 KiB)

Any one an idea?

[betacentauri]

Hi Pedro,

 

I guess you can use the 1800 for the -c parameter. It only says that the generated UBIFS cannot have more than COUNT logical erase blocks. It's only a problem when you want to use a backup from one box in another box which have more flash memory. Well, it's not very likely that many will do it. Perhaps et9000 users who buy an et9200.

Or use some high value like 8192 (=1GB flash with 128KB erase block size). I don't think it will make problems while flashing.

 

It's only a guess. Perhaps some other knows it better. Well, you can test with 1800 or 8192 and look whether there is a problem.

[Pedro_Newbie]

So the number 4096 in the parameter -c for the UBINIZE arguments can be used beyond the real limit?<br />Real is, in this example, 1800 used is 4096.<br /><br />As I understand this has no negative consequences and I could also use e.g. the number 12000 without consequences?<br />