From the output of ubinfo -a
Size: 115 LEBs (14602240 bytes, 13.9 MiB)
Size: 133 LEBs (16887808 bytes, 16.1 MiB)
The kernel was discussed as it explains why a 16 MB sysupgrade image results from a 14 MB ROM.
oh .
but that would mean that I have a 14M ROM and a 16M rootfs_data (which is shown in the third post in ibuinfo commnad.
but I still get the 13MB available space.
that is my issue.
the difference between 16M and the actual 13M I get for all the stuff I can write to it.
is this that 7MB you said it needs for stuff?
I think we found out that the kernel part is a constant 6M so from 34MB for ROM(which you say doesn't include kernel) I have a 14MB ROM and and almost 3MB for the reserved blocks and then I still don't get the whole other almost 16M but 13MB?
34 becomes 32.9 then reversed blocks gets subtracted and it becomes ,as you said, 30.5 then from this 30.5 I subtracted the 14MB ROM and then I should get more than 16M for rootfs_data which the ubi shows.
but if df I still get 13MB in total.
See the technical information on UBIFS, linked above
Remember also that NAND isn't a disk -- there are 124 kB erase blocks and you can't just write bits to NAND the way that you do to an SSD or spinning-platter disk. You have to erase before you can write, and the writes are a page at a time. It's a major dance that is hidden from you by the UBI drivers.
To write, you need to erase a block (or find one that is already erased where you need to write), fill the cache register (2048 bytes, for this chip), then write the entire 2k to the NAND memory itself. So, to change a few bytes, you often need to change where the data is, and the file system needs to keep track of that all. It doesn't impact the ROM in the same way, as it is read-only and handled differently.
1 Like
thanks for all the answers.
now as a last guesstimate can I assume (If I don't get bad blocks and so on) that I have almost 13+14=27M for my image (minus the 2MB kernel)?
so I can for example create an image that is almost 26MB(minus the kernel) and write that to the device?
I am not gonna do that , I am just playing devil's advocate.
You have about 13.9 + 16.1 MB = 30 MB for your ROM and overlay combined. That is based on the total size of the two UBI volumes on your running system.
As you note, it wouldn't be wise to get anywhere near that limit.
On a Linux system with ext4 you are not using a raw flash chip but a hard drive, a SSD, a SDCard or USB flash drive.
They are all devices with a storage controller that does this job behind your back. You never know how much real capacity is used to deal with the actual storage system hardware.
For example on NAND chips you need to store parity information and checksums for ECC (error correction) as the type of storage technology is NOT reliable enough to just write it as-is. On a SSD or flash drive or sdcard this is done by the storage controller and you don't see it at all.
Plus the whole eraseblock thing that jeff is talking about above.
Plus UBIFS is running compression on what you write in it to give you as much space as possible.
What you see is a known issue, but there isn't much that can be done on a raw flash filesystem.
That's why on anything bigger and more expensive than cheap embedded devices you have SDcards, CompactFlash, eMMC, SSDs and hard drives instead of this nonsense.
It's a hassle that is best let deal with to a dedicated storage controller.
See here for the official documentation of UBIFS about it http://www.linux-mtd.infradead.org/faq/ubifs.html#L_df_report
UBIFS flash space accounting is quite challenging and it is not always possible to report accurate amount of free space. The df utility usually reports less free space than users may actually write to the file-system, but it never reports more space.
UBIFS cannot precisely predict how much data the user will be able to write to the file-system. There are several reasons for this - compression, write-back, space wastage at the end of logical eraseblocks, garbage-collection, etc. Please, refer this section for details.
Note, JFFS2 also has problems with free space predictions, but on average, it reports free space much more accurately. However, JFFS2 may lie and report more free space than it actually has. For example, we experienced situations when JFFS2 reported 8MiB free space, while we were able to write only 2 MiB of data. This makes some user-space applications very unhappy.
UBIFS also lies, but it always reports less space than the user may actually write. For example, it may report 2MiB of free space, but if you start writing to it, you may be able to write 4MiB (even if you have compression disabled).
Thus, the only way to find out precise amount of free space is to fill up the file-system and see how much has been written.
2 Likes
ty for all these
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.