limits and default values of the maximum I/O size.

[PAUL CHEN_2]

My machine is rp5470 and running 11i.

Thanks.

[Navid Hussain_1 · Accepted solution]

Hi,

Here is the answer to your query -

1) Using raw disk devices, the maximum I/O transfer size is 1 megabyte.

2) Using LVM (Logical Volume Manager), the maximum I/O transfer size is 256
kbytes.

3) Using LVM with LVM striping, the maximum I/O transfer size is limited to the
size of your strip or at most 256k.


The disk io drivers will also try to combine the requests, so it's possible to
have a larger I/O transfer size, but since this is not easily calculated, there
is no way to know what the highest io transfer size could be.

Cheers ..

NAVID HUSSAIN

[Stan Sieler]

Re:

> 1) Using raw disk devices, the maximum I/O transfer size is 1 megabyte.

Hmmm...our diskperf product seems to be
able to read larger chunks. I just
tested it, and did a successful read
of 8 MB from /dev/rdsk/c1t15d0
(an HP 18.2GMAN3184MC drive).

I also tried a 32 MB read...seemed to
work, but I didn't dump the data to
visually inspect it :)

[A. Clay Stephenson]

Your box can do larger than the maximum physical read size reads (or writes) because when a larger read is requested, the read() system call silently breaks them into maximum physical read size chunks advancing the buffer pointer after each read so that to the application this is invisible and appears as one operation.

[Stan Sieler]

how do we programmatically obtain the
max physical transfer size, then?

thanks!

[A. Clay Stephenson]

echo "scsi_maxphys/D" | adb /stand/vmunix /dev/kmem

[Stan Sieler]

thanks!

BTW, I was hoping for a formal programmatic method, as in sysconf() (Which, BTW, shouldn't be only for configurable variables, but that's
a different issue :))

I prefer OS-provided/supported functions for things like this because mechanisms that rely on running other processes aren't: (a) fast; or (b) fundamentally reliable; (c) portable. HP-UX needs to talk to vCSY about AIFSYSWIDEGET :)

[A. Clay Stephenson]

Get used to disappointment; sysconf won't do it for you. You can read the value from header files but that's even less reliable. Unfortunately using adb (or equivalent techniques) to read the kernel's symbol table and then read kernel memory is about as close as it gets in HP-UX. For HP-UX boxes the values are either 256KB (10.20) or 1MB (11.x) but that could change without notice. It really doesn't matter because of the way HP-UX breaks io's into smaller chunks. I suspect that if your metric tries to do 10 1MB reads or 1 10MB read the differences are going to be neglible.