On 09/ 6/10 08:43 AM, Jan Damborsky wrote:
Hi guys,
I am evaluating fix for DC bug 16714 and I am again contemplating
getting rid
of fiocompress(1m) mechanism which takes care of compressing eligible files
in Sparc boot archive. Last time we were considering this with Jack and
Alex,
we decided to postpone the decision until DDU projects gets integrated.
These are 'pros' of removing compression step
(detailed evaluation is captured in bug 6361)
* simplified DC manifest (no need for 'fiocompress' attribute)
I'm hesitant to sign off on completely removing support; I can see the
case for not using it (though see below) but don't see this particular
simplification as being that attractive.
* faster DC build
* simplified code - all stuff related to dcfs compression can be removed
* no strange issues reported against Sparc coming from dcfs(7F)
limitations -
e.g. compressed files can't be updated
In order to find out what we would be sacrificing, I have compared
AI boot archives based on 147 - the first one underwent compression
step during DC build, the second one skipped it:
# df -h /tmp/ba
Filesystem Size Used Avail Use% Mounted on
/tmp/iso/platform/sun4u/boot_archive
178M 134M 44M 76% /tmp/ba
r...@tia:/export/home/dc# df -h /tmp/ba1
Filesystem Size Used Avail Use% Mounted on
/tmp/iso1/platform/sun4u/boot_archive
178M 162M 16M 92% /tmp/ba1
From those results, it could be observed that
* memory requirements would not change on AI Sparc client, size total size
of boot archive remain the same (this is due to the fact that DC
currently
does not take compression into account when calculating size of Sparc
boot
archive - bug 6361)
Would fixing 6361 make any significant difference in the memory
requirements on SPARC? If so, that's the only reason I would consider
continuing to use dcfs.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
