On Wed, Mar 19, 2008 at 06:01:31PM +0100, Casper.Dik at Sun.COM wrote: > >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 have no idea what the underlying issues are and since it's a rare > [...] > > So it's not a power cycle, but a "panic & sync disk". That should > give some form of on-disk consistency.
Maybe we can come up with a test, perhaps involving zones and fault injection. > >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. > > Yep, unfortunately the way UFS works is that it only cares about meta > data and that's as far as consistency checking goes. Then I don't see how SMF/SQLite can protect itself. I mean, the contents of /etc/inet/hosts on my laptop had been *completely* replaced with some other file's content (I forget which). I wonder if the fact that the system came up without forcing single-user mode (to manually fsck /) had anything to do with that. There is simply no way any application can protect itself against such brain damage from the FS. > >How can SMF protect itself against UFS damage? > > I'd assume that's a task of the database engine; but there is more too it > than that because SMF transactions also need to be grouped. Well, see above. > (E.g., a manifest import is likely to consist of many database updates but > in all is only a single transaction). Sure, that should be one transaction. > Coincidentally, the recent putback which makes all manifest imports > happen in memory may make this problem largely go away. I sure hope so! > >> 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_. > > But putting it in their will make certain things worse: such as the > familiarity with other OSes. Again, the config file wouldn't go away; the purpose of this proposal is to make it easier to setup new instances that differ very little from the default instance, not to completely change how sshd is configured. Altogether I sense enough resistance that it wouldn't be an easy ARC review, so I doubt I'll bother :) Also, it's really up to Jan, and he doesn't seem to like it either. Nico --
