David Bustos writes: > Quoth Hans-Joerg on Fri, Aug 24, 2007 at 04:23:59PM -0700: > > Do you have any recommendations for me? I must say, that my sympathies > > for the Solaris Volume Manager is somewhat limited these days. A hard > > disk crash shouldn't arise such a situation. > > Without knowing more about what happened in the past, I don't think > I can comment on how well SVM performed. And even if I did, I don't > know particularly much about SVM anyway. > > > Anyway there should be > > a way to salvage this damn SQLite-file and get SMF in consistent state > > without a reboot. > > Well the svc_nonpersist.db file is kept on a tmpfs filesystem, which is > usually kept in memory, but I suppose could be swapped out to disk. So > if a disk which swap is kept on fails, then I suppose the file could be > corrupted. So we could teach SMF to try to be more resilient to disk > failure by mirroring the file to another disk (such as the root > filesystem), but I think it would be better for SMF to instruct the > kernel that the file should not be swapped out to disk, which should > reduce the liklihood of corruption down to the liklihood of memory > failure. Or perhaps invent a way to reconstruct the essential > information from whatever data the kernel keeps about processes. (Which > would require storing the mapping between FMRIs and contract IDs in the > kernel, to have any chance of being effective.) > > > David > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org
Alternatively, you can use SVM to mirror swap. tom
