On Wed, Mar 19, 2008 at 05:06:55PM +0100, Jan Pechanec wrote: > On Wed, 19 Mar 2008, Casper.Dik at Sun.COM wrote: > > >Secondly, SMF has already proven to me to be too fragile because either > >the underlying database technology is not reliable or the way it uses > >that technology is prone to failures. Powercycling a system during > >certain parts of boot is almost guaranteed to cause the next boot to > >fail with a corrupted registry. The fact that that is even possible > >concerns me greatly; recovery is easy but requires manual intervention.
I'm real curious about this. For example, would upgrading to SQLite3 help? Or is there a fundamental problem with SQLite2 that is not not changed in 3? Or can SMF recover more intelligently? Or is this more of a UFS reliability issue that ZFS boot will help with? I recently accidentally pulled the power cord on my laptop while shutting down. The battery was out (I leave it out when at home to extend battery life). When the system came up a number of files were corrupted, like /etc/inet/hosts, and fsck didn't catch that -- the system just reached multi-user as if nothing had happened. I had to manually fsck -y the filesystems, and that found a fixed lots of problems, but not the corruption of /etc/inet/hosts. How can SMF protect itself against UFS damage? The way SQLite works it keeps a journal during transactions. The journal provides both, locking and a way to rollback transactions that are in progress when the writer dies (e.g., reboot). Perhaps this approach + UFS unreliability just don't mix. But even if SQLite had a ZFS-like COW approach to transactions internally it might still not mix with UFS unreliability. > this is quite an important point given the fact that sshd is the > only remote (login) service started by default. Putting sshd config into SMF won't make that worse. If the SMF configuration repository is corrupted then sshd won't start, and that's _today_. Nico --
