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