Re: [PATCH RFC] nvme-multipath: fix diskstats for partitions
John Garry <[email protected]> Fri, 24 Jul 2026 08:09:51 +0100
| Newsgroups | org.infradead.lists.linux-nvme,org.kernel.vger.linux-block |
|---|---|
| Organization | Oracle Corporation |
| Message-ID | <[email protected]> |
On 24/07/2026 06:01, Christoph Hellwig wrote: > On Tue, Jul 21, 2026 at 11: 45: 53AM +0000, John Garry wrote: > Setting as an > RFC as adding this extra bio field is not acceptable, but I > can't see how to > lookup the original partition. In general it is not, but you should mark this a > > > On Tue, Jul 21, 2026 at 11:45:53AM +0000, John Garry wrote: >> Setting as an RFC as adding this extra bio field is not acceptable, but I >> can't see how to lookup the original partition. > > In general it is not, but you should mark this a block patch so that > Jens can better cream at you :) > > I'm also not sure that supporting per-partition diskstats on a multipath > device makes too much sense, but then again there's a lot of setups > that are crazy and actually used.. > It just seems to me that we should have same behaviour as if it were not multipath. So we can't use bi_private as that can be set by original bio submitter. I was thinking that this bdev pointer could be temp stashed in bi_next (as it should be originally NULL), but that it dodgy and maybe won't even work. Least worst I can think if is to alloc some temp memory per-bio in nvme_ns_head_submit_bio() to hold this bdev pointer and original bi_private, set bio->bi_private to that memory, and then set bi_private back to original when we end the bio. But this is all crappy, especially just for partition diskstats.