On 09/10/10 05:29 AM, Jan Damborsky wrote:
On 09/ 8/10 04:27 PM, Dave Miner wrote:
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.
I see. Thinking about how we might approach this and looking at DC
manifests,
it seems there is already XML tag we could take advantage of here -
in particular we currently have following in <boot_archive> section:
<boot_archive>
<!--
If/how to compress the boot archive. Valid
types are gzip and none
-->
<compression type="gzip" level="9"/>
[...]
</boot_archive>
It is currently used only by x86 platform. I am thinking
that we could enhance its scope and use it for Sparc as well.
That would also help with DC manifests looking consistent
across platforms, since currently this x86 specific section
resides in Sparc DC manifests where it is irrelevant.
For Sparc manifests, that section might be modified in
following way:
<boot_archive>
<!--
If/how to compress files boot archive. Valid
types are 'dcfs' and 'none'.
For 'dcfs', uncomment related </boot_archive_contents>
section specifying list of files which have to be left
uncompressed.
-->
<compression type="none"/>
[...]
</boot_archive>
Please let me know if it might sound as a reasonable approach.
Sure, that seems like an improvement and relatively reasonable, though I
wonder if we could do something more automatic around per-file
compression determination based on file permissions or pkg attributes on
file actions.
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)
I agree with Ethan that 6976104 might take advantage of those 30MB.
On the other hand, since it seems we communicate 1G as minimum memory
for Sparc AI, do we still need to keep 512MB Sparc AI scenario working ?
Memory limits are subject of some discussion. I don't have an answer
right now.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
