本文共 1738 字，大约阅读时间需要 5 分钟。
轉載自
ubifs size問題討論
It is a form of specifying file-system size. But instead of specifying the exact file-system size, this option defines the maximum file-system size (more strictly, maximum UBI volume size). For example, if you use --max-leb-cnt=200 mkfs.ubifs option, then it will be possible to put the resulting image to smaller UBI volume and mount it. But if the image is put to a larger UBI volume, the file-system will anyway take only first 200 LEBs, and the rest of the volume will be wasted.
Note, the --max-leb-cnt option does not affect the size of the resulting image file, which depends only on the amount of data in the file-system. mkfs.ubifs just writes the --max-leb-cnt value to the file-system superblocks.
This feature is quite handy on NAND flashes, because they have a random amount of initial bad eraseblocks (marked as bad in production). This means that different devices may have slightly different volume sizes (especially if the UBI feature is used). So you may specify the maximum possible volume size and this will guarantee that the image will work on all devices, irrespectively on the amount of initial bad eraseblocks.
Fundamentally, mkfs.ubifs has to know file-system size because UBIFS maintains and stores per-LEB information (like amount of dirty and free space in each LEB) in so-called LPT area on the media. So obviously, the size of this area depends on the total amount of LEBs, i.e. on the volume size. Note, various characteristics of the LPT B-tree depend on the LPT area size, e.g., we use less bits in LPT tree keys of smaller LPT area. So do not use unnecessarily large --max-leb-cnt value to achieve better performance.
转载地址：http://dwpgi.baihongyu.com/