Operating System - HP-UX
1752810 Members
5917 Online
108789 Solutions
New Discussion юеВ

Re: vxfs snapshot overhead ?

 
Leif Halvarsson_2
Honored Contributor

vxfs snapshot overhead ?

Hi,

Is there any overhed when accessing files from an vxfs snapshot (compared to accessing from the "original" filesystem).

We have some strange performance problems showing a very high "wio" when running a dbcheck from a snapshot.

(rx2660, HP-UX 11.23, application is "clearcase")





3 REPLIES 3
Steven E. Protter
Exalted Contributor

Re: vxfs snapshot overhead ?

Shalom,

If the dbcheck involves writes to the snapshot filesystem the situation is expected.

clearcase is something I work with on Linux and HP-UX and it can be quite troublesome and at times I/O intensive.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Leif Halvarsson_2
Honored Contributor

Re: vxfs snapshot overhead ?

Hi,

Thank you for your reply.

Do you run any dbcheck on the clearcase database ?

On snapshot filesystem ?

Have you checked the load on the system when dbcheck is running (using e.g. sar or glance) ?

In our case, most of the time dbcheck is running, "usr" and "sys" activity is only a few %, rest is "wio". Somtimes, almost all the load is "wio". At that time, some copy operations seems to happen.

Example:

cp -Rp /backup/wds_swt.vbs/db /tempo/db_checklog/db_copy

(/backup is a snapshot filesystem)

Know very little about clercase myself. I have only been asked to have a look at the performance issue of the server.





A. Clay Stephenson
Acclaimed Contributor

Re: vxfs snapshot overhead ?

Bear in mind that a snapshot is read-only so that talking about writes on a snapshot is a non sequiter. In most cases, the snapshot overhead is small and hardly noticeable. The exception to that is a very write intensive original filesystem. Just before a given block is write()'en to (FOR ONLY THE FIRST TIME SINCE THE SNAPSHOT BEGAN), the OS must first write the original contents of the block to the snapshot buffer device and then write() to the original filesystem block. This means that each write() is often translated to two write()'s. When read()'s occur on the snapshot, the change map is consulted to see if that block has been altered, if not, it is read() from the original filesystem otherwise it is read from the snapshot buffer. One of the things that does choke down a filesystem when doing sequential reads is if the mount options mincache=direct,convosync=direct.
If it ain't broke, I can fix that.