Jan Damborsky wrote: > Hi Alex, > > I have given those changes a try and while DC build succeeded > for Sparc and x86 AI images, number of available inodes > were insufficient for nbpi=16384 in x86 LiveCD case for both > 32 as well as 64 bit archives. > > So I have taken a closer look at boot archives based on build 128 - > observations are summarized in tables below. > > From this it seems that 16384 is sufficient for AI images, 8192 > is needed in LiveCD case. > > I am thinking about following solutions: > > [1] Specify nbpi in DC manifests. > Looking at DC manifest, there is already section <boot_archive> > which is used to set boot archive parameters - e.g. > compression type (<compression>) or padding (<size_pad_mb>). > We could add support for nbpi. > > [2] Work out algorithm which would automatically calculate nbpi > during process of creating boot archive. > For instance, nbpi might be function of ramdisk size and > number of inodes: > nbpi = f(size of backend file, number of required inodes) > > [3] ? > > > I think mentioned approaches have their pros and cons, e.g. > > [1] > + user can set it to the desired value > - if size or content of boot archive changes in such a way that > build of boot archive fails, manual intervention is required - > nbpi has to be recalculated > > [2] > + no need to calculate the value manually > - less control - user can't set it to the desired value > > Please let me know what you think. Since the nbpi is a way to tune the size of the boot archive, I think that we should provide a way for users to specify different values so they can try out what works best for the problem they are solving.
I think we can provide both option 1 and 2 you mentioned above. By default, have the value be calculated automatically, and display what value is used in the log file. If users want to try out a different value, they can specify the number to use in the manifest, and that number will be used, and no automatic calculation is done for them. Thanks, --Karen > > Thank you, > Jan > > > Tables: > > [1] size of ramdisk backend file [kB] - uncompressed in case of x86 > > For instance for AI x86 64 bit archive the size was obtained using > following steps: > > # gzcat /tmp/iso_ai/platform/i86pc/amd64/boot_archive > > /tmp/boot_archive_ai_64 > # du -sk /tmp/boot_archive_ai_64 > 159400 /tmp/boot_archive_ai_64 > # > > ----------------------------------------- > cd_32 cd_64 ai_32 ai_64 ai_sparc > ----------------------------------------- > 144452 177132 114256 159400 170968 > ----------------------------------------- > > > > [2] # of used inodes > > fsck(1M) was used to obtain this information, e.g. > # fsck -v /tmp/boot_archive_ai_64 > ... > > Filesystem summary: > Inodes in use: 6977 > Blocks in use: 128994 > Total free fragments: 28385 > Free fragments not in blocks: 225 > Total free blocks: 3520 > Fragment/block fragmentation: 0.1% > > > ---------------------------------------- > cd_32 cd_64 ai_32 ai_64 ai_sparc > ---------------------------------------- > 14892 15095 6775 6977 7310 > ---------------------------------------- > > [3] # of available inodes > > Obtained experimentally - filesystem was filled up > with 1byte files. > > ----------------------------------------------- > nbpi cd_32 cd_64 ai_32 ai_64 ai_sparc > ----------------------------------------------- > 8192 17854 21286 - - - > 16384 9918 11838 7678 10878 11518 > ----------------------------------------------- > > Legend: > cd_32 x86 LiveCD 32bit boot archive > cd_64 x86 LiveCD 64bit boot archive > ai_32 x86 AI 32bit boot archive > ai_64 x86 AI 64bit boot archive > ai_sparc Sparc AI boot archive > > >>> Alex, >>> you are quite welcome. >>> >>> Could you please send me your changes by means of 'hg >>> bundle' ? >>> >>> Thank you, >>> Jan > >>> Done. >>> >>> -- >>> Alexander > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
