On 09/ 8/10 07:29 AM, Jan Damborsky wrote:
Hi Dave,
thank you very much for your comments, please see my response in line.
Jan
On 09/ 7/10 09:55 PM, Dave Miner wrote:
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 that we could still use it in AI and get rid of it for text
installer where content of boot archive is copied to the target,
so there is higher probability that dcfs(7fs) related issues get
propagated to the target system.
Is this kind of trade off which you are envisioning here or
would you contemplate something different ?
I would probably be fine with just leaving the support in the code, but
not using it in the DC manifests for either image type right now. Note
that we may not keep these images separate, anyway, so the scenario you
describe above may not be possible from a Solaris product point of view.
I can see the case for not using it (though see below) but don't see
this particular simplification as being that attractive.
I agree that this particular point would be kind of added value here,
but not the
strong argument.
I think the main problem with using dcfs(7f) is the cost of evaluating
related issues.
And potentially propagating them to the target in case of text installer,
even if they might not be perceived as problems from boot archive point
of view -
e.g. bug 16714.
Sure, I agree.
* 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.
We would save ~30MB of memory ending up with 16MiB of free space in boot
archive.
The real question is whether that 30 MB changes the minimum requirements
for SPARC in any significant way (i.e. makes 6979560 or 6976104 less of
a problem)
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
