Slow backup times to new volume

[Donald Robichaud]

First, let me say I know what I am trying to do is unsupported, but I have been asked to try so I am wondering if anyone had the issues I am seeing.

We bought 6 StorageWorks shelves, 2 HSJ50 controllers and 24 RZ1FB-VW disk drives a while back. Our reason for buying the 36.4 GB drives was to reduce our current three Storgeworks boxes with dual HSJ pair controllers to two or even possibly one box. Since our current environment grew over time we have many Raidsets with 9 GB drives and since the limiting I/O factor in our CI cluster has always been the limitation of the CI our HSJ controllers were underutilized (usually the max I/O being under 25% capacity of the controller).

Our current VMS mixed Vax/Alpha cluster is running VMS 6.1 on the Vax side and VMS 7.1-2 on the Alpha side. Don't ask. Myself and the other VMS system manager wanted to bring the entire cluster up to VMS 7.3 but
the request was denied by management. When we bought the HSJ50 controllers they came with HSOF V57. This would not work with our Vax side of the cluster. We had the vendor ship us HSOF V52 since that is the version we are
running on our three other HSJ controller pairs. But we found that with HSOF V52 we were limited in the size of the lun we could create. We could not create a Raidset using using our 36.4 GB drives spanning all six shelves. We found this was a limitation of the HSOF firmware. We then found that HSOF V54 would support the size lun we wanted to create. We were limited to HSOF V54 because it is the latest rev of the firmware we can run on the Vax side of the cluster. After much searching we were able to purchase two HSOF V54 cards and were able to create luns and have both versions of the operating system see them.

In our testing we found that database backups to this 355486275 block volume seemed slow. I setup a test that backed up the same 818770 blocks size directory tree to and from various targets. When I backed up to a current 177736020 block volume, that is very fragmented, the time was 4 minutes and 30 seconds. When I backed up the same directory tree to the new 355486275 block volume, just initialized, the time was 16 minutes and 11 seconds. Thinking that maybe the cluster size of 341 may be causing a problem, even though the larger cluster size should facilitate writing, at least larger files, I created a partition half the size (177742075 blocks). This is also the exact size of my older volume that backed up faster. Unfortunately I got the same results. Could there be any other reasons I am seeing this slower backup time? I was suspicous when I had such a hard time finding the HSOF V54 cards and begged HP to tell me, even in a NBA context, if there were any issues with that card, but hit a wall of silence. Thanks for any help you can give me.

[Andy Bustamante]

The first thought that comes to mind, did you initialize the new volume with the /nohighwater switch?

Questions, what sort of raidset is the existing unit (raid-1, raid-5, raid 1+0 ) and what is the new unit?

Andy

[Donald Robichaud]

Thanks Andy. The volume was initialized with all the default values including file high water marking. Both volumes are Raid5.

[Hein van den Heuvel · Accepted solution]

Maybe the writeback cache on the Raid5 units is not working? Bad battery? Bad License?

Hein.

[Donald Robichaud]

Thanks Hein. That was it. Writeback cache was not enabled. I had done it with our old firmware and thought I did it with HSOF V54. Operator error. 8^)

[Andy Bustamante]

The highwater option is a security measure, enabled by default in VMS. On allocation disk space is erased to avoid reading data which might have been previously existed.

Depending on your business needs and security requirements:

Try:

$ set volume /nohigh

You can use

$ show device /full

to see if highwater is enabled on the current unit.


Andy

[Hein van den Heuvel]

Andy wrote...

"The highwater option is a security measure, enabled by default in VMS. On allocation disk space is erased to avoid reading data which might have been previously existed. "

Actually... This is NOT true for most usages.

The erase does not happen on allocation but on operations which set the EOF beyond a point where data has been known to be written (the high water mark).
So specifically for backup and copy style operations High Water Marking has NO effect, as those operations write data to all blocks before updating the EOF mark.

Operations where HWM does have an effect and may cause a slowdown are
- SET FILE /EOF (you are not supposed to use that)
and
- Application program using 'random access' writes to a file. eg QIOW + WRITEVBLK to a VBN beyond the last written VBN.

Hope this clarifies some,
Regards,
Hein.

[David Jones_21]

Hein wrote...
"Andy wrote...

'The highwater option is a security measure, enabled by default in VMS. On allocation disk space is erased to avoid reading data which might have been previously existed. '

Actually... This is NOT true for most usages."

Good object lesson in 'first impressions'. The initial implementation of highwater marking (V3?) was sub-optimal and the 'common wisdom' of highwater marking being a big performance hit entrenched itself pretty quickly. It doesn't matter that it was fixed before Alpha's even existed.