Hello,
Using 2.6.16.20 with lpfc and scsi_debug, I wasn't able to get blocks larger
than 512KBytes.
(should be the same with 2.6.17-rc6)
My test:
writting 10000 blocks, block size is 1MByte (=> 10 GBytes):
[root@iotiger2 ~]# cat /proc/diskstats | grep sdk
8 160 sdk 3 3 768 28 0 0 0 0 0 28 28
[root@iotiger2 ~]# dd if=/dev/zero of=/dev/sdk bs=1M count=10000
10000+0 records in
10000+0 records out
[root@iotiger2 ~]# cat /proc/diskstats | grep sdk
8 160 sdk 3 3 768 28 20007 139993 20480000 11271532 0 77680 11271556
=> there have been ~20000 ops (which means that block size is 512KBytes)
The 512KBytes size is also reported on the storage array side when using lpfc
driver with a NEC 2400 system.
Then, I try to change BLK_DEF_MAX_SECTORS in include/linux/blkdev.h.
=> Using a value of 4096, IO blocks where 2MBytes large.
Now, locking at the block layer implementations, seems that there may be
something wrong with blk_queue_max_sectors.
I know that max_sectors is set to 0xFFFF in the lpfc driver, and I was expecting
to get the block layer queue max_sectors sized according to the low level driver
max_sector.
but we have the following affectations:
q->max_hw_sectors = max_sectors
q->max_sectors = BLK_DEF_MAX_SECTORS
why q->max_sectors isn't set to max_sectors too ?
I've did a try with q->max_sectors=max_sectors and I was able to use 8MBytes
blocks (measured from diskstat and from the NEC storage system too)
So, what is the nice way to change the block layer for getting large IO blocks
(> 1024 sectors) ?
Best regards
--
Frederic TEMPORELLI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
