Operating System - HP-UX
1833876 Members
1894 Online
110063 Solutions
New Discussion

Setting issue in mount option help!!!

 
SOLVED
Go to solution
Gordon_3
Regular Advisor

Setting issue in mount option help!!!

Hi all,

We are running 11i and vxfs version 4 to create filesystem. Our standard for mounting filesystem is "suid, largefiles, delaylog, datainlog 0 2". We have test a disks array ( with cache in their own disks array ) and simulate a sudden power lost situation, after resume the disks arrayd AND reboot the hosts, we found some files are lost after fsck, they cannot be found in lost+found neither. So just want to know if above setting has some explanation on the root cause of the problem.


Syslog of the system:

Jun 14 16:12:47 testigni vmunix: If the diaglogd daemon is not active, use the Daemon Startup command
Jun 14 16:12:47 testigni vmunix: DIAGNOSTIC SYSTEM WARNING:
Jun 14 16:12:47 testigni vmunix: in stm to start it.
Jun 14 16:12:47 testigni vmunix: If the diaglogd daemon is active, use the logtool utility in stm
Jun 14 16:12:47 testigni vmunix: to determine which I/O subsystem is logging
excessive errors.
Jun 14 16:12:48 testigni vmunix: DIAGNOSTIC SYSTEM WARNING:
Jun 14 16:12:48 testigni vmunix: The diagnostic logging facility is no longer
receiving excessive
Jun 14 16:12:48 testigni vmunix: errors from the I/O subsystem. 8 I/O error
entries were lost.
Jun 14 16:14:17 testigni vmunix: msgcnt 22 vxfs: mesg 037: vx_metaioerr - /dev/vgora/Foratest file system meta data read error
Jun 14 16:14:17 testigni vmunix: msgcnt 23 vxfs: mesg 016: vx_ilisterr - /home/oratest file system error reading inode 25
Jun 14 16:14:17 testigni vmunix: DIAGNOSTIC SYSTEM WARNING:
Jun 14 16:14:17 testigni vmunix: The diagnostic logging facility has started
receiving excessive
Jun 14 16:14:17 testigni vmunix: errors from the I/O subsystem. I/O error en
tries will be lost
@

Can any expert here correlate the option "delaylog" & "datainlog" WILL cause this problem? My personal feeling is that it definitely will lead to data loss ( file is not update ) but NOT the whole file missing, any idea? thx.

Bgds,
Gordon
Gordon
3 REPLIES 3
Stefan Farrelly
Honored Contributor
Solution

Re: Setting issue in mount option help!!!


Youre dead right, the delaylog option is causing your problem. The default is log (not delaylog) which means that changes are logged on disk before a system call returns to an application. This is safe. Delaylog isnt. See man 1m mount_vxfs for all the detail on log/delaylog etc.

Most people change it to delaylog for performance reasons, as we do, as log has a performance impact. Youve got to balance this against the very small chance of a power outage. At my current site weve only have one in 3 years and all our oracle databases recovered/rolledback perfectly afterwards. It depends on what application you are running as to wether you have to use the safer log option or can run with delaylog.

Change it to log and retry your powerfail tests. Im sure it will be much better.
Im from Palmerston North, New Zealand, but somehow ended up in London...
Gordon_3
Regular Advisor

Re: Setting issue in mount option help!!!

HI Stefan,

Thx for your quick reply, but as u mentioned, the changes is lost due to it's in cache, this is also what we believe. I just thinking we lost the "changes", but not the whole file, can u explain a little more as I am still confuse about this point. Also according to yr experience, how about the datainlog affect this situation? Many thx in advance.

Bgds,
Gordon
Gordon
Stefan Farrelly
Honored Contributor

Re: Setting issue in mount option help!!!

Hi Gordon,

datainlog is a default option (if you have OnlineJFS installed) so no need to specify in fstab - its already on. The only option we use in /etc/fstab is delaylog (and datainlog is on by default). This is for performance reasons as mentioned before. If you want even more performance you can use nodatainlog. Some servers with oracle databases where we need extra performance we use the following options;

delaylog,mincache=direct,convosync=direct,nodatainlog 0 2

This, under certain conditions, will bypass the server unix cache and go direct to the hardware device (disks) so good peformance but not the best for reliability in the event of a power failure.

Just to check - have you got the latest VXFS patches installed ? this is very important.

I would think that yes - your delaylog option could cause your entire file to be lost. If the TOC or file is in the middle of being updated when you suffer a power outage it could lose the entry completely. Try it with the log option, you should definitely not lose anything with this option.

Im from Palmerston North, New Zealand, but somehow ended up in London...