Question about make_request_fn based block drivers

From: scameron
Date: Wed Mar 20 2013 - 18:00:00 EST



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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/