Steve Peng wrote: > Hi All, > > During the code review phase for the following smf performance improvement: > > 6351623 Initial manifest-import is slow > > http://cr.opensolaris.org/~stevep/6351623-2 > > One of David's recent comments from the code review brings up my > intention of sending this email and soliciting your opinion. > > The question is what's the best thing to do if we fail copying the tmpfs > repository back to the root file system after a successful services > import. The current implementation is to switch the repository back > to the /etc/svc/repository.db (may be stale) if we fail the copy. The > original reason for doing this is if we don't switch back, we may stay > on the tmpfs repository for a long period of time and may suffer more > loss of customization in case of the system crash. So basically I am > looking for the best solution to address this. There are couple of > known alternatives: > > (1) exit svc.configd and put the system in maintenance mode > (2) retry copy operation but this really doesn't address the problem > IMO.
I prefer that for now we go into maintenance mode. When we do full early-manifest-import, it'll be time to think harder about increasing support for the read-only root scenario, but there's no value in that for this putback which only moves to tmpfs during the (late) manifest-import. That said, exiting svc.configd isn't going to be sufficient since startd will restart it. I'm guessing you're suggesting something like failing the switch operation, having manifest-import exit with SMF_EXIT_ERR_FATAL and printing an appropriate recovery message to the screen to help the admin, and having configd restarted by startd to flush the cache. But, can you be more detailed about your plans for #1? thanks, liane
