Got it! It is fixed now!! Just one line fix, like last time. The drive capacity is 1 more than the value returned by READ_CAPACITY. Since the value we were setting was not a multiple of 4K, all the I/O were coming in the lowest accessible size of 512 bytes.
Sumant gave me the idea to explore this angle and see what capacity we are setting. Earlier, I created a dummy block driver (ramdrive - sbull) of 1024 blocks and found it always gets 4K IO. Changing the size to 1023 made us get 512 byte I/O. I am going to push the changes to github. Thanks, Chayan > -----Original Message----- > From: scame...@beardog.cce.hp.com > [mailto:scame...@beardog.cce.hp.com] > Sent: Wednesday, March 20, 2013 2:59 PM > To: linux-kernel@vger.kernel.org > Cc: stephenmcame...@gmail.com; scame...@beardog.cce.hp.com; Chayan > Biswas; elli...@hp.com > Subject: Question about make_request_fn based block drivers > > > When running mke2fs against the make_request_fn based block driver > I'm working on, I'm seeing only single-block bios. Other such drivers > (e.g. nvme) are getting, for example, 4k bios coming in from the same > mke2fs command. > > mke2fs /dev/sop0 > > This is on a 3.9-rc1 kernel. > > I've tried setting: > > blk_queue_max_hw_sectors(rq, 2048); > blk_queue_max_segments(rq, 32); > blk_queue_io_opt(rq, 4096); > blk_queue_io_min(rq, 4096); > blk_queue_physical_block_size(rq, 4096); > blk_queue_logical_block_size(h->rq, 512); > blk_queue_physical_block_size(h->rq, 4096); > > all to no avail. > > If I do this: > > dd if=/dev/sop0 of=/dev/null bs=4k iflag=direct > > with that, I can get 4k bios coming in to the make_request_fn. > > Driver source is here: https://github.com/HPSmartStorage/scsi-over-pcie > (still a work in progress -- that source doesn't do all the blk_queue_* > settings mentioned above, those are just the things I've tried.) > > In /sys/block/sop0/queue... > > [scameron@localhost queue]$ for x in * > > do > > echo ===== $x ====== > > cat $x > > done > ===== add_random ====== > 1 > ===== discard_granularity ====== > 0 > ===== discard_max_bytes ====== > 0 > ===== discard_zeroes_data ====== > 0 > ===== hw_sector_size ====== > 512 > ===== iostats ====== > 1 > ===== logical_block_size ====== > 512 > ===== max_hw_sectors_kb ====== > 1024 > ===== max_integrity_segments ====== > 0 > ===== max_sectors_kb ====== > 512 > ===== max_segments ====== > 32 > ===== max_segment_size ====== > 65536 > ===== minimum_io_size ====== > 4096 > ===== nomerges ====== > 2 > ===== nr_requests ====== > 128 > ===== optimal_io_size ====== > 4096 > ===== physical_block_size ====== > 4096 > ===== read_ahead_kb ====== > 128 > ===== rotational ====== > 0 > ===== rq_affinity ====== > 1 > ===== scheduler ====== > none > ===== write_same_max_bytes ====== > 0 > [scameron@localhost queue]$ > > Any ideas what I'm missing to get I/O's bigger than 1 block to come in? > > Thanks, > > -- steve ________________________________ PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
