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.
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
>>>
>>>
>>
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>
>
