Jean McCormack 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. >> >> > I really like this solution and it works in with what is in the code. > Instead > of the filelist we use the manifest. > > Jean > Hi Jean,
I am confuse about what you mean by the "filelist we use in the manifest"? Which filelist are you talking about? Thanks, --Karen >> Thanks, >> Jack >> >> >> 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 >
