HI Dave.
On 12/17/08 08:25, Dave Miner wrote:
> Jack Schwartz wrote:
>
>> Karen Tung wrote:
>>
>>> Jack Schwartz wrote:
>>>
>>>> Another idea for your consideration:
>>>>
>>>> change the manifest spec. There is a
>>>> <base_include type="file"> type of entry. We could introduce a
>>>> <base_include type="uncompress_file"> type of entry. Then
>>>> bootroot_initialize could make a list of files which shouldn't be
>>>> compressed based on this, and can pass that file to bootroot_archive
>>>> for proper handling.
>>>>
>>>> Thanks,
>>>> Jack
>>>>
>>>>
>>> It is a good idea to specify the additional list of files that shouldn't
>>> be fiocompressed in the manifest. It works well with the DC's goal
>>> of having 1 single file to describe how the image is created.
>>>
>>> I have a slightly different suggestion. I would do:
>>>
>>> <base_include type="file" fiocompress=false>
>>>
>>> The fiocompress is optional. If not specified, it will be compressed.
>>>
>>> I think this is more clear than saying type="uncompressed_file", because
>>> this uncompress_file concept is only when we do fiocompress. For x86,
>>> there
>>> won't be such option.
>>>
>> To make this great idea even better, how about just "compress=false"
>> instead of "fiocompress=false". That way, if in the future a different
>> kind of compression is utilized, the attribute name will still fit.
>>
>>
>
> Overall, the idea of making this an attribute in the manifest sounds
> reasonable. A couple of things:
>
> - dcfs will likely be used on x86 before too long, too, so don't design
> this too specifically for SPARC
>
This attribute would be present for both SPARC and X86. Whether we use
it for both is another matter.
> - I would be hesitant to make the property name too general here; as Jan
> points out, this is really a workaround for a dcfs-specific limitation
> that may be fixed, so it's not clear that generalizing is beneficial
>
> Dave
>
When I spoke yesterday to Jan Setje-eilers I wasn't under the impression
that he thought this was a dcfs bug to be fixed. Being that each file
is compressed individually, he said just don't compress the files which
will be needed for update.
(Cc'ing Jan in case I misread him.)
Even if dcfs would be "fixed" down the road, I don't see harm in using a
more general term for the attribute name. To me the generality has more
potential to keep the name valid over time. Even if it gets yanked,
what is the harm in using a more general term?
Thanks,
Jack
>
>> Thanks,
>> Jack
>>
>>> Thanks,
>>>
>>> --Karen
>>>
>>>
>>>> On 12/16/08 15:57, Jack Schwartz wrote:
>>>>
>>>>
>>>>> Hi everyone, especially Karen and Jan.
>>>>>
>>>>> Regarding the dcfs / fiocompress issue with the bootroot:
>>>>>
>>>>> fiocompress is a per-file compression. One solution to the issue
>>>>> which came up this morning around updating compressed files is to
>>>>> not compress the files which will be opened for update. This should
>>>>> be only a few files*, such as database files, which need to keep
>>>>> most of their old data.
>>>>>
>>>>> * Note: even vi opens files O_RDONLY to read them in, then opens
>>>>> them O_WRONLY|O_CREAT|O_TRUNC to write out the changed version.
>>>>>
>>>>> To try to work around this in other ways seems limited. Jan and I
>>>>> talked this morning about passing -e to svcadm to get around this
>>>>> problem when adding a service, but then what about devfsadm, where
>>>>> the problem also shows? For now, I assume we'll copy an
>>>>> uncompressed file.
>>>>>
>>>>> In order to keep things simple, since there are only a few files
>>>>> which require this special handling, I suggest copying all, then
>>>>> recopying the few files which don't require compression.
>>>>>
>>>>> In fact, DC already does this for the files in
>>>>> boot/solaris/filelist.ramdisk (see bootroot_archive.py). Perhaps
>>>>> this concept can be extended to include an additional list of
>>>>> files. There are other solutions, but this one would likely plug
>>>>> into what is already in place in the easiest way.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Thanks,
>>>>> Jack
>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20081217/d599d4cd/attachment.html>
