So I figure that I might start to ramble about the things that I see causing the most problems for admins.
I'm simply amazed at how many things in Solaris that I think are pretty obvious and have been around for a while that aren't used.
UFS Logging being the least of them.
UFS logging has been around since Solaris 7. Considering that Solaris 7 has been out since pre-2000 days and that there aren't lots of people that still use Solaris 2.6, you'd figure that we'd have these kind of features set on all of the systems out there.
Nope.
So what is logging? From the mount_ufs man page:
logging | nologging
If logging is specified, then logging is
enabled for the duration of the mounted
file system. Logging is the process of
storing transactions (changes that make up
a complete UFS operation) in a log before
the transactions are applied to the file
system. Once a transaction is stored, the
transaction can be applied to the file sys-
tem later. This prevents file systems from
becoming inconsistent, therefore eliminate-
ing the need to run fsck. And, because
fsck can be bypassed, logging reduces the
time required to reboot a system if it
crashes, or after an unclean halt.
The default behavior is nologging for file
systems less than 1 terabyte. The default
behavior is logging for file systems greater
than 1 terabyte and for file systems
created with the -T option of the newfs
command or the mtb=y option to the mkfs_ufs
command.
The log is allocated from free blocks on
the file system, and is sized approximately
1 Mbyte per 1 Gbyte of file system, up to a
maximum of 64 Mbytes. Logging can be
enabled on any UFS, including root (/). The
log created by UFS logging is continually
flushed as it fills up. The log is totally
flushed when the file system is unmounted
or as a result of the lockfs -f command.
Clear as mud, right? Lets put it in simpler terms. If the system crashes, and you have logging on, you don't need to fsck the entire filesystem. All you need to do is look at the log. The log will tell you what was being changed from a filesystem metadata perspective (there is no way to guarantee the actual data was written completely, you'd need a different type of filesystem to do that.) This makes your fsck take seconds instead of minutes (or hours for really big filesystems).
This is even more important in that Solaris fsck will stop and await input if it finds an inconsistency in the filesystem that would cause data to be changed or files to be removed. So your big, busy E25K crashes due to something (bad driver, hardware problem, vodoo) you're going to possible have lots of temporary files around. As the fsck might encounter them and determine that the way to make the filesystem consistent is to remove them. So it sits an prompts the user. As this is done before the filesystem is mounted you're sitting there with your E25k in single user mode waiting for input while your business is at a standstill. Not good.
Enabling logging is simple. Just add "logging" to the /etc/vfstab for the options field of the filesystem that you want. All ufs filesystems can do this.
What about performance?
From everything I've read, all of the old performance bugs for UFS logging have long since been fixed. Performance should be the same or better with logging turned on.
With Solaris 10, logging will be the default.