From: hch@lst.de (Christoph Hellwig)
Subject: Block Integrity Rq Count Question
Date: Tue, 12 Dec 2017 09:39:51 +0100 [thread overview]
Message-ID: <20171212083951.GA923@lst.de> (raw)
In-Reply-To: <MWHPR04MB1025EDA7D10216C24D00C573EA300@MWHPR04MB1025.namprd04.prod.outlook.com>
On Fri, Dec 08, 2017@10:04:47PM +0000, Jeffrey Lien wrote:
> I've noticed an issue when trying to create an ext3/4 filesystem on nvme device with RHEL 7.3 and 7.4 and would like to understand how it's supposed to work or if there's a bug in the driver code.
Can you reproduces this on Linux 4.14 / Linux 4.15-rc, please? The
code in bio_integrity_prep should allocate the right number of
bio_vec entries based on what the device asks for, and for NVMe that's
always 1 in Linux as we don't support SGLs for the metadata transfer.
>
> When doing the mkfs command on an nvme device using lbaf of 1 or 3 (ie using metadata), the call to blk_rq_count_integrity_sg in nvme_map_data returns 2 causing the nvme_map_data function to goto out_unmap and ultimately the request fails. In the blk_rq_count_integrity_sg function, the check "if (!BIOVEC_PHYS_MERGEABLE(ivprv, iv))" is true causing a 2nd segment to be added. This seems like it could happen regularly so my question is why the nvme driver map data function is only ever expecting 1 segment?
>
> Jeff Lien
> Linux Device Driver Development
> Device Host Apps and Drivers
> jeff.lien at wdc.com
> o: 507-322-2416 (ext. 23-2416)
> m: 507-273-9124
>
>
>
>
>
---end quoted text---
next prev parent reply other threads:[~2017-12-12 8:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-08 22:04 Block Integrity Rq Count Question Jeffrey Lien
2017-12-08 22:19 ` Keith Busch
2017-12-11 17:54 ` Jeffrey Lien
2017-12-12 0:00 ` Keith Busch
2017-12-12 8:39 ` Christoph Hellwig [this message]
2017-12-12 14:34 ` Jeffrey Lien
2017-12-12 21:17 ` Jeffrey Lien
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=20171212083951.GA923@lst.de \
--to=hch@lst.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.