On Sun, Mar 29, 2026 at 11:12 AM Charles-Antoine Couret via lists.openembedded.org <[email protected]> wrote: > > Le 29/03/26 à 18:15, Richard Purdie a écrit : > > For context, these previous versions were in 2023. I think the general > > concern is we already have a lot of rootfs size related variables and > > adding more of them complicates the user interface. It isn't clear > > which ones "win" when multiple conflicting settings are made. > > > > In this case the max size "wins" above any of the others. > > IMHO this makes sense because it's more specific and related to the real > filesystem size. > > But indeed if you want to change the design behind, I'm open to it. > > > It does > > appear that it isn't just a max size but a fixed size in that it will > > pad the filesystems to this size? That makes the name a bit > > confusing/misleading and was one of the concerns last time. > > In fact I realize that I've not read your previous answer last time, too > focus on the CI error. Sorry, my mistake. That's why I've not taken this > into account for my recent changes. > > Yes, this variable is doing both (fixed + max size of the filesystem), > due to how filesystem tools are working. Maybe by having a more > "intrusive" change, we can improve it. > > > What I can suggest is: > > * IMAGE_ROOTFS_MAXSIZE would be used against filesystem sizes, and not > against precomputed rootfs sizes as done today, it's likely not really > relevant to keep current behavior as it. I don't know if we would be > able to customize the value per filesystem type as done in my proposal > or if a global setting is good enough. > > * if IMAGE_ROOTFS_EXTRA_SPACE is set to 0 and IMAGE_OVERHEAD_FACTOR set > to 1.0, don't provide size parameter to mkfs to create a dynamic and > minimal filesystem, to avoid the need to always provide manually extra > margin just for filesystem overhead > > * Then introduce a new variable like IMAGE_ROOTFS_FIXED_SIZE which can > be provided (if set) to mkfs tool to have a fixed partition size > whatever are the other settings related to rootfs size. If unset (by > default), previous logic can be used instead.
Perhaps a better option would be some sort of "IMAGE_ROOTFS_ALLOW_GROW" variable that controls if an image can actually grow beyond the IMAGE_ROOTFS_SIZE + overhead amount? The current code basically takes the max of IMAGE_ROOTFS_SIZE & the actual install size to determine the size, but this variable could supress that to make it only look at IMAGE_ROOTFS_SIZE. It could also set IMAGE_ROOTFS_MAXSIZE to the sum for additional checks? I think this would fit into the current model of how these size variables work without needing to introduce a completely new variable that does different math? > > > I'm not an expert of all filesystems so maybe this suggestion can > introduce problems. I don't see potential regressions for current users > as well. > > What do you think? Another ideas? > > > Thank you for your feedback. > > Regards, > > -- > > Charles-Antoine Couret > > Embedded Software Developer > > +32 488 27 56 40 > Website <https://mind.be> • LinkedIn > <https://www.linkedin.com/company/mind_essensium/> • Newsletter > <http://eepurl.com/h-gy7v> > > <https://mind.be> logo > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#234250): https://lists.openembedded.org/g/openembedded-core/message/234250 Mute This Topic: https://lists.openembedded.org/mt/118563509/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
