Steve Peng writes:
>
> 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.
>
> Let me know what do you think.
>
>
> TIA
>
> Steve
>
>
>
> _______________________________________________
> smf-discuss mailing list
> smf-discuss at opensolaris.org
I'd like to raise a few questions associated each of these solutions.
(1) exit svc.configd and put the system in maintenance mode
When svc.configd gets restarted, should it pick up the tmpfs
repository and try to copy it to permanent storage again? Perhaps
the administrator fixed the underlying problem while in maintenance
mode.
(2) retry copy operation but this really doesn't address the problem
Should we retry forever in hopes that the admin will fix the
problem with the root file system? If we eventually give up
retrying, we're back to the original question. Do we continue to
run with the tmpfs repository, because it has the current
information? Or do we switch back to the stale permanent
repository? Depending on what caused the copy failure, we may just
find that we have problems with the permanent repository also.
tom
