UFS stability issues 2

[MrTom]

i've had some bad experiences so far in using UFS, but i don't really know how bad they were.
basically, some tests i've been doing for pre-production machines envolved cutting power to the machine and seeing how well it could cope. i was dissapointed to find that the whole thing lost control of UFS even when the server was at 0.0 load. also to make me even more shocked, it lost UFS when i did a "sync" at the ok prompt.
each time i had to manually fsck the /var partition using the -y option and things seem ok. the trouble is i can't tell whether it is ok, or what the point in me running fsck manually was if i'm just going to use "-y". i'm not prepared to spend an hour at 3am going thru 1000's of possible errors.
is what i have done just what everyone does or have i missed something more important in my setup?

 

[cfsalmeida]

In Solaris 7/8 you can use "logging" for ufs logging, if you are using UFS in SDS you can use a metatrans device.
UFS Logging was introduced with SDS and has now been integrated into Solaris 7 and 8, it is disabled by default. when UFS logging is enabled on a filesystem, the integrity of the filesystem is maintained through the use of transaction logs.
For use UFS logging in "/etc/vfstab" use keyword "logging" in field "mount options" and reboot., then you can use mount
command to check if logging is active.

Hope it helps,

Carlos Almeida,

 

[marrow]

Hello Mr.Tom,

While it is good to test for all possibilities, my early knowledge of Sun Systems was to never power them off while the system and it's disks are running otherwise serious disks errors could occur. My advice is therefore please don't do this, even if a power failure occurs and you no have no UPS, so be it, but don't go looking for trouble.

The Stop A facilty may be employed in extreme cases to halt a machine but the system is generally recoverable afterwards. As for "fsck -y", well you don't have to answer yes 1000's of times, if you did you might actually hit the wrong key and answer incorrectly to one of the questions. I would always use fsck "y" and out of hundreds of boxes practised upon over the years I don't remember losing a system after fsck was executed. Besides the error messages are frightening and it's best not to see them! If your system is in trouble, it'll soon let you know.

In my experience - the answer to your question is, if you rough up the system it will complain, therefore this is fairly normal behaviour and probably nothing wrong with your setup, but normally fsck -y should come to the rescue if you have problems.

Hope this helps

 

[MrTom]

ah! this all sounds like good stuff

i take it that the logging will have a negligible impact on disk performance? is it ok/wise to have logging on all partitions?

when i said cutting power i meant i was just doing a poweroff from lom. i wanted to see what would happen, and it's probably just as well i did
it's nice to know that -y is ok, i've never really had to fsck anything before.

thanks guys!

 

[frankj]

that thing of UFS logging sound real nice, welcome back Carlos...

FJ,

 

[cfsalmeida]

if you don't want (or can't) reboot just to activate/de-activate "logging" you can use eg:

# mount -o remount,logging /

re-mount filesystem with ufs logging.

Regards,

Carlos Almeida,

 

[FarahRegal]

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
&quot;think twice and hit enter once&quot;