The blocksize which is exposed to the SAN is 512 bytes. I think Scott mentioned that support for variable blocksize is in the works.
The I/O comstar issues to its backend is not based on the backend. Its based on the requested I/O size and the buffer space it can allocate from the port provider (in this case qlt driver). qlt has fixed buffers of several sizes starting from 128K, all the way down to 512 bytes. Depending upon the I/O load a given I/O may or may not get a 128k or 64K buffer. This should probably be a tunable but currently its not. If you are seeing comstar issuing small sized I/Os to the backend, its probably becasue either the requested I/O size from the initiator is 512 bytes or there are too many I/Os piled up in sbd (too high load or backend too slow). Sumit -----Original Message----- The fixed blocksize is per LU. Different LU's can have different blocksizes, but they are currently determined automatically, based on the backing store for the LU. On Apr 10, 2009, at Apr 10,1:15 PM, Sumit Gupta wrote: > > > >The heart of what I've discovered is that COMSTAR picks a block > size based on the device behind it, and appears to *always* >issue > IOs using that block size, no matter what the size of the requests > coming in across the wire. If the block device is >zvol, it uses > the zvol record size, which makes sense. If the block device behind > it is a physical disk, or SVM volume, it >picks 512 bytes as the > block size. > > Do you mean the I/O to the COMSTAR's backend ? Or the blocksize of > the device exposed to the SAN ? > > Sumit >
_______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
