On 09/13/10 05:19 AM, Jan Damborsky wrote:
On 09/10/10 04:18 PM, Dave Miner wrote:
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.
That is good suggestion. In that case, do you think it might
still make sense to provide user with possibility to list additional
files not eligible for compression in DC manifest or should it be
only possible via defining appropriate pkg attribute (TBD) for particular
file action ?
I'd allow the list. The idea above is more about how to make
compression as automated as possible to limit the need for the list.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
