Re: Split I/Os to contiguous file???
From: Glenn Everhart (gce_at_gce.com)
Date: 06/19/04
- Next message: David J Dachtera: "Re: VMS Gets Short Shrift at HP World."
- Previous message: kathystoltz_at_hotmail.com: "Re: Proved my point: JF Mezei is the troll"
- In reply to: mckinneyj_at_cpva.saic.com: "Re: Split I/Os to contiguous file???"
- Next in thread: Bob Koehler: "Re: Split I/Os to contiguous file???"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 18 Jun 2004 21:40:38 -0400
Most if not all SCSI port drivers limit transfers to 64KB. This
is less of a real issue on SCSI disks than it might appear since
dkdriver will have many I/Os sent to the drive, to be executed at
drive speed, if the disk supports tagged queueing. It does affect
tape max blocksize, but that is not really a performance issue on
modern tapes much; they have an underlying block structure (and
lots of ECC) which means long records don't really save tape like
they do on 9track.
The reason for not boosting the port driver I/O size has been mapping
resources in the controllers (and to some extent the processors). If
most of the mapping resources get tied up for the duration of a large
I/O, other I/O gets starved. In a PC situation the response seems to
be to expect folks not to do large I/O unless they have some reason to
want it. In VMS, the design is to avoid letting any one user tie up
resources enough to materially screw up another. "User" in this case
can be person or just some process...the same logic applies, and the
application case is perhaps more common. Thus while port drivers with
larger max SCSI I/O have been written (in some it's just setting a
maximum size parameter up and recompiling as I recall), they are not
used.
There is also the unwillingness to have extra long single operations
where the system might have to wait for them to clear. That too can
take longer for very large operations. That situation occurs more often
than you might think: the XQP often forces read or writecheck (there is
a sysgen parameter to control it) and that check operation forces the
disk driver to single stream mode, i.e., waiting for everything else. Any errors do
that too, but they are less common.
Glenn Everhart
mckinneyj@cpva.saic.com wrote:
> In article <bdc65a53.0406180924.49bc3df0@posting.google.com>,
> gspamtackett@yahoo.com (Galen) writes:
>
>>My application performs write QIOWs to a single multi-gigabyte
>>contiguous file (created contiguous-best-try but actually contiguous
>>since it has only one mapping pointer in its header). MONITOR
>>PROCESS/TOPDIO shows that it is the only process doing any significant
>>direct I/O.
>>
>>When the application is running, MONITOR IO shows a high rate of split
>>I/Os, about 200-300 per second. Using some browser-based
>>instrumentation built into one of my disk controllers (a KZPDC
>>SmartArray 5304A) I can see that the largest I/O being performed at
>>the controller is only 256 blocks, while my application issues its
>>QIOs for multiple thousands of blocks per I/O.
>>
>>This same behavior apparently occurs using an identical file via a
>>vanilla internal builtin SCSI controller and drive. (I can't observe
>>the actual I/O sizes for this hardware, but I can see that the level
>>of split I/Os and the DIO rate both are similar to what I see on the
>>KZPDC.)
>>
>>What is causing the I/Os to be split, when the file is contiguous??
>>Does the "magic" 256-block maximum actual I/O provide any clues?
>>
>>This is an OpenVMS V7.3-2 EV6 500MHz ES40 with 1 GB RAM that is
>>current on ECOs, except that my FIBRE_SCSI V2 may not be the newest.
>>(The release notes for the newest FIBRE_SCSI don't appear to say
>>anything that might be related to this issue.) It is not clustered and
>>I am the only user, running the only "user" application (the rest is
>>HP TCP/IP, DECnet and Web-Based Management Agents.)
>
>
> I recall that the SCSI disk drivers used to limit the size of a
> disk transfer - result being split I/Os when you exceeded this
> limit. Don't recall what the limit is/was - but your description
> suggests its still there with a value of 256 blocks for DKDRIVER -
> perhaps someone else will follow-up to confirm this.
- Next message: David J Dachtera: "Re: VMS Gets Short Shrift at HP World."
- Previous message: kathystoltz_at_hotmail.com: "Re: Proved my point: JF Mezei is the troll"
- In reply to: mckinneyj_at_cpva.saic.com: "Re: Split I/Os to contiguous file???"
- Next in thread: Bob Koehler: "Re: Split I/Os to contiguous file???"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
