Hi Jack,
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. As far as SMF services are concerned, they are enabled/disabled by DC according to ai_generic_live.xml file. As we don't currently enable/disable services explicitly during boot of AI image, we would only need to use svcadm(1M) with -t option when debugging/testing in the AI environment. As far as problem with /etc/dev/.devfsadm.lock is concerned, I think we could delete that file during boot before devfsadm(1M) is invoked. With respect to coreadm SMF service failing, we might just disable it in ai_generic_live.xml for now. > > 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. I like your idea to implement this workaround in Distro Constructor (DC), since it would make easy to workaround any other issue related to that dcfs limitation. Also, after dcfs is fixed, it would be easy to get rid of this, since it would be located at one place in DC. That said, since I am not aware of how much work is involved if we decide to enhance DC for this, given the fact that the code introduced would be just temporary solution until dcfs is fixed, it would need to be evaluated if the effort invested will pay off. Thank you, Jan > > Thoughts? > > Thanks, > Jack > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
