On Mar 19, 2008, at 1:50 PM, Mike Shapiro wrote: > On Wed, Mar 19, 2008 at 09:37:22AM -0700, Henry B. Hotz wrote: >> >> On Mar 19, 2008, at 9:06 AM, Jan Pechanec wrote: >> >>> On Wed, 19 Mar 2008, Casper.Dik at Sun.COM wrote: >>> >>>> Powercycling a system during certain parts of boot is almost >>>> guaranteed to cause the next boot to fail with a corrupted >>>> registry. >> >> Wow! I do I even need to say what that implies about SMF? >> >> This entire thread sounds a lot like the old SysV vs BSD debate. >> It's >> actually amazing that Sun survived the decision to abandon their >> (working) BSD for (broken/buggy) SysV. I don't think it was until >> about 2.4 that Solaris began to be a decent alternative. > > sqlite bugs aside, what you're describing is no different than > how your system won't boot if your filesystem has corrupted etc/ > system, > or the kernel binary, or the boot archive, or the extended partition > table, or any of a thousand other things. On Linux. Or Windows. > Or SVR4. > > If you want to have a system which survives power-cycling in the > middle > of arbitrary activity to the root filesystem, then you need either > (a) a > transactional filesystem like ZFS (which is why we're making ZFS root > the default), or (b) a journaled filesystem which always recovers > properly > and doesn't have any log replay bugs.
By its nature bootup is (or should be anyway) a read-only activity for config files. I was reacting to the claim that rebooting during boot could corrupt SMF's configuration. (Granted that claim may have been exaggerated.) I do not believe that it is reasonable system design to allow an interrupted read to corrupt something that is critical for the system to operate. If (and I say IF) SMF were designed so that was possible then I would regard that as sufficient justification to junk it and start over. The fact that SMF's internals are so deliberately opaque makes it impossible for a typical admin to see if that is the case. The fact that so many people (who don't want to) are *required* to deal with SMF means there are a lot of people who need that assurance who won't get it. As I have said before, I do not know enough about SMF to have a technical opinion. However from a marketing and customer confidence standpoint it is clearly a disaster. The intensity of opinions on this thread raise the question of whether the "official channels" are appropriate. Marketing and customer relations issues should be dealt with by the appropriate management, not a technical development process. It would appear that someone inside Sun should forward this thread to the appropriate management. ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
