Oh... OK. "fiocompress" it is.
Dave, you, and Karen (I just asked her verbally) all think fiocompress
is a better choice...
Thanks,
Jack
On 12/17/08 12:41, Jean McCormack wrote:
> I was thinking about the naming issue here. If you use compress=false
> then that could lead
> the user to imply that this file will always be uncompressed even if
> you're not using
> fiocompress. For now that implies all x86 builds. And this would
> definitely not be true.
> If you use fiocompress=false it's more clear what you are really doing.
>
> Jean
>
> Jack Schwartz wrote:
>> 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
>>>>>>>
>>>>>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>
>
