From: scameron@beardog.cce.hp.com
To: linux-kernel@vger.kernel.org
Cc: stephenmcameron@gmail.com, scameron@beardog.cce.hp.com,
chayan.biswas@sandisk.com, elliott@hp.com
Subject: Question about make_request_fn based block drivers
Date: Wed, 20 Mar 2013 16:58:38 -0500 [thread overview]
Message-ID: <20130320215838.GO30284@beardog.cce.hp.com> (raw)
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
next reply other threads:[~2013-03-20 21:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 21:58 scameron [this message]
2013-03-20 22:01 ` Chayan Biswas
2013-03-20 22:21 ` scameron
2013-03-20 22:28 ` Chayan Biswas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130320215838.GO30284@beardog.cce.hp.com \
--to=scameron@beardog.cce.hp.com \
--cc=chayan.biswas@sandisk.com \
--cc=elliott@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stephenmcameron@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®