linux-kernel - RE: Question about make_request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <E821E2F372F08945977BD15EAE588D61097E8222@SACMBXIP02.sdcorp.global.sandisk.com>
Date:	Wed, 20 Mar 2013 22:01:19 +0000
From:	Chayan Biswas <Chayan.Biswas@...disk.com>
To:	"scameron@...rdog.cce.hp.com" <scameron@...rdog.cce.hp.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	"stephenmcameron@...il.com" <stephenmcameron@...il.com>,
	"elliott@...com" <elliott@...com>,
	Sumant Patro <Sumant.Patro@...disk.com>
Subject: RE: Question about make_request_fn based block drivers

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: scameron@...rdog.cce.hp.com
> [mailto:scameron@...rdog.cce.hp.com]
> Sent: Wednesday, March 20, 2013 2:59 PM
> To: linux-kernel@...r.kernel.org
> Cc: stephenmcameron@...il.com; scameron@...rdog.cce.hp.com; Chayan
> Biswas; elliott@...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@...alhost 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@...alhost 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/