BladeSystem Forums have moved here
To make BladeSystem information easier to find, we have moved the BladeSystem forums here, to Servers and Operating Systems.
System Administration
Showing results for 
Search instead for 
Do you mean 

vxfs snapshot overhead ?

Honored Contributor

vxfs snapshot overhead ?


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")

Exalted Contributor

Re: vxfs snapshot overhead ?


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.

Steven E Protter
Owner of ISN Corporation
Honored Contributor

Re: vxfs snapshot overhead ?


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.


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.

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.