pvtimeout on 11.23 (ia-64)

[KPS]

Hi,

We have an rx8640 connected to an EMC DMX-3. EMC has recently looked at our setup from a grab utility and is telling us to correct our pvtimeout and set it to a value of 90.

Our current pvtimeout is set to default as far as IO Seconds go. Could someone tell me what the default value of seconds equals on HP-UX 11.23 IA-64?

Thanks,
KPS

[KPS]

I forgot to add that the device driver that we're using to see these SAN Devices is sdisk.

[A. Clay Stephenson · Accepted solution]

The default i/o timeout value is 30 seconds --- which is fine for a standalone disk but is marginal for an array LUN. Normally, array LUN's are set somewhere in the 90-180 second range unless a vendor supplies a specific value.

[James George_1]

In an EMC environment , the recomanded value is 90 OR 180 .


# pvchange â t 90 /dev/dsk/cxtxdx ( either 90 or 180 is fine)

Also, On all the logical volumes make bad block re allocation to None.

# lvchange â r N /dev/vgxx/lvolxx ( Please not that the â -r â n â will turn it off but to make it NONE we have to use â r â Nâ !!)

Rgds / James

[Edward Finneran]

Some things to keep in mind though - it's the recommended setting from EMC to set the pvtimeout to a high value, as mentioned.

However, if you have multiple paths to the DMX, either out separate host fibrechannel adapters, potentially going through separate fibrechannel fabrics to separate FA ports on the DMX, this will increase the amount of time before the host tries this alternate path.

So if the host does an I/O, and the DMX is not responding on the primary path for whatever reason (maintenance on the DMX, firmware upgrades, rolling resets through the fibre adapters, etc.), rather than waiting 30 seconds before it retries the I/O on the second path, it will wait 90 or 180 seconds. It's going to be up to you to know, as LVM forces the requesting application to wait for this I/O to complete - what is the behavior of the application? If it's a simple cp or tar command, then it will wait, and the activity will just take longer. However, there are many pieces of software that will not wait, and will start exhibiting problems.

If you have a database package, for example, which is configured to use asynchronous I/O, it could wake up and go - hmmm... 45 seconds since I asked for that piece of information from the disk, eh? Well, then, I'm going to fail that transaction back to the client.

Any disk subsystem that's going to take longer than 30 seconds to return an I/O may have profound effects on the 'upstream' applications passing on the request.

One thing the increased timeout value definitely WILL due is reduce the number of pvlink failover messages that you receive. If you know your apps can tolerate it, and you're interested in decreasing the frequency of the messages, then the increase will do that for you.

[Denver Osborn]

Are you using EMC's powerpath too? They'll recommend setting to 90 and that you don't use pv links. "So if the host does an I/O, and the DMX is not responding on the primary path for whatever reason..." powerpath will take care of it for you if properly configured.

-denver