Using logging
Starting with Solaris 7, there's a new logging option to the mount command and in the /etc/vfstab system configuration file. Logging only appears in a couple other places within Solaris. The mount command shows which partitions are mounted and lists logging in the options fields for each partition on which logging is enabled. Finally, at system boot time, the fsck phase reports per partition whether each is stable, logging, or being checked. There are no other status commands available to determine the state of logging.
But does it work?
As with any new feature from an operating systems vendor, a bit of skepticism and try-before-you-buy attitude is helpful. To test the performance and functionality of UFS logging, we used an Ultra 10 running Solaris 8. A quick script to do 1,000 directory creations put plenty of pressure on the metadata handling of UFS:
# more logging-test
#!/bin/ksh
# Test ufs logging performance
# Get to the right place and make a test directory
cd /big
mkdir test
# Create 1000 directories
integer i=0
while ((i < 1000))
do
mkdir test/test${i}
i=i+1
done
The first test was done with logging disabled (the Solaris 7 and 8 default):
# time ./logging-test
real 27.7
user 2.0
sys 4.9
# time rm -rf test
real 8.0
user 0.0
sys 0.3
The result was 35.7 seconds for the directory create and delete. Next, logging was enabled and the same test was run:
# umount /big
# mount -o logging /big
# time ./logging-test
real 13.2
user 1.7
sys 5.4
# time rm -rf test
real 0.8
user 0.0
sys 0.2
The same commands with UFS logging enabled took 14 seconds to complete, a significant savings.
The next test was even more fun. With no logging, I power-cycled the Ultra 10 during the directory create script.
The result was not pretty. At boot, the system went into single-user mode and a manual fsck was required to repair the damage to the file system on /big. After typing in many y responses to the various questions, the file system was again consistent and could be booted.
Trying the same test with logging enabled resulted in a pleasant and quick
/dev/c0t1d0s2: is logging
message during fsck, and the system booted without any issues.
There were some early bugs with UFS logging, so be sure to have the latest kernel patch cluster installed on your systems before enabling logging. It's also wise to test that feature in a QA lab or in another nonproduction environment.
Logging increases performance, decreases fsck time, removes the risk of a file system corruption, can be used on all UFS partitions (including root), and is free. It obviously receives a two thumbs, way up rating.
Another mount option
There's another relatively new and useful option you should be aware of. It's the noatime mount option.
Without noatime, every time a file is opened for read, its access time i-node value is updated. That is useful for listing the date and time the file was last read, as displayed with the ls -u command.
There are many instances in which either the last access time is not interesting, keeping it up to date is too much overhead, or both. Web server contents (static text pages, for instance) and Usenet news directories are two good examples. In those instances, the overhead of performing one i-node write for every file open is quite heavy.
The noatime mount option decreases the frequency of access time update. Essentially, it tells the system to only update the access time if another update to the i-node is being done coincidently. No harm is done, especially on file systems where there's no interest in the last access time information.
From Itworld
Peter Baer Galvin, Unix insder .
Farah regal
good luck
"think twice and hit enter once"
