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. 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 >
