Conference turris::digital_unix

	It depends on what the disk is connected to.  If directly
	connected to a SCSI adapter it should be 16 MB - 1 byte.
	Since disks prefer to transfer multiples of sectors, it
	would end up at 16,776,704 bytes.  To do an I/O that size
	to a raw device you'd:

		rc = read(fd, buffer, 16776704) ;

	where, the fd is a file descriptor for the open device.  And,
	if the device doesn't happen to support I/Os that large, the
	driver should take care of breaking it up into smaller I/Os.
	For disks connect through an HSZ, the maximum I/O size is
	64 KB.  MSCP may be 64 KB as well, but that would be driver
	limit instead of an architecture limit.  I'm not sure about
	the backplane RAID controllers.

    re .0
    I guess one of the critical points here is: to how many KZPSA's can the
    EMC system be hooked up to?
    
    There are several layers in the Unix kernel limiting a single I/O to
    64 KB: UFS, LSM, drd. And if I remember correctly the Oracle kernel
    itself limits raw I/O's to 64KB. So even using a database block size
    of 32KB will not get you past the 64KB limit.
    
    BTW. the 200MB/sec on the Sun was that number monitored while Oracle
    was accessing the disks or was that some artificial I/O load? In any
    case that number isn't too shabby.
    
    	Martin

    re .2
    OK so much for opening my big mouth before checking again. I just tried
    a recent release of Oracle (7.3.2) and found the hardcoded limit for
    read I/O is 128KB (not 64KB). I tried with 2 db_block_size settings and
    the Oracle kernel will automatically limit the
    db_file_multiblock_read_count parameter; with:
    
    	db_file_multiblock_read_count * db_block_size <= 128KB
    
    I also checked the I/O transfer size and yes when Oracle reads from a
    raw disk (no LSM, drd, or the like) I actually see 128KB reads.
                       
    	Martin

Martin,

we were told by Oracle Presales Support here in Spain that such limit is 
platform dependant. They also told us that 128 KB is the limit for Sun 
Solaris. For Digital UNIX on Alpha they thought there is a hidden way (?) to 
set it up to something higher. Hopefully, they are looking how to do it (?)

Regarding the configuration we're going to use in the benchmark, we will 
use most of the EMC disks and partitions in raw mode without LSM. It's a 
single machine, so there's not any DRD service. We are going to use 32 
KZPSA connected to 32 FWD ports in the Symmetrix.

By the way, in the HiTest configuration material for Oracle Data 
Warehousing, they reveal a way to increase the 64 KB limit of LSM by 
patching the UNIX kernel in the following way:

# kdbx -k /vmunix /dev/mem
(kdbx) p volinfo.max_io
(kdbx) patch volinfo.maix_io 640
(kdbx) quit

This is to get a maximum single I/O transfer size of 640 physical blocks, 
512 KB each.

Best regards,
Juli�n Rodr�guez
Digital Spain Technical Presales - UNIX Ambassador
DTN: 874-4192  

Hi

 I think there are limits in both CAM and LSM for 64KB default
I/O size.  These can be changed by changing the variables either
via sysconfigtab or dbx.

Note that this needs to be done in both places (if you are using both),
and one needs to be sure the SCSI device/controller being used
can handle this.

In general, patching the kernel won't be the big win in this...the main
thing is that the application does multiple I/Os, that are reasonably
large, such that we can keep the device busy.

You can't guarrantee device behaviour in all this due to things
like caching, disk banding, bad block replacement...etc...so again,
the application and how it does I/O is the key component...

LSM is generally important to allow striping across multiple
controllers.