From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: data corruption with 'splt' workload to XFS on DM cache with its 3 underlying devices being on same NVMe device Date: Tue, 24 Jul 2018 10:42:41 -0700 Message-ID: <20180724174241.GA828@infradead.org> References: <20180723163357.GA29658@redhat.com> <20180724130703.GA30804@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20180724130703.GA30804@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Mike Snitzer Cc: linux-block@vger.kernel.org, dm-devel@redhat.com, linux-nvme@lists.infradead.org List-Id: dm-devel.ids On Tue, Jul 24, 2018 at 09:07:03AM -0400, Mike Snitzer wrote: > True. We only ever support mapping the partitions ontop of > request-based multipath (via dm-linear volumes created by kpartx). > > > So, have you tested that request-based multipathing works on a > > partition _at all_? I'm not sure if partition mapping is done > > correctly here; we never remap the start of the request (nor bio, > > come to speak of it), so it looks as if we would be doing the wrong > > things here. > > > > Have you checked that partition remapping is done correctly? > > It clearly doesn't work. Not quite following why but... blk_insert_cloned_request seems to be missing a call to blk_partition_remap. Given that no one but dm-multipath uses this request clone insert helper, and people generally run multipath on the whole device this is a code path that is almost never exercised. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.133]:39922 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388414AbeGXSuS (ORCPT ); Tue, 24 Jul 2018 14:50:18 -0400 Date: Tue, 24 Jul 2018 10:42:41 -0700 From: Christoph Hellwig To: Mike Snitzer Cc: Hannes Reinecke , linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, dm-devel@redhat.com Subject: Re: data corruption with 'splt' workload to XFS on DM cache with its 3 underlying devices being on same NVMe device Message-ID: <20180724174241.GA828@infradead.org> References: <20180723163357.GA29658@redhat.com> <20180724130703.GA30804@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20180724130703.GA30804@redhat.com> Sender: linux-block-owner@vger.kernel.org List-Id: linux-block@vger.kernel.org On Tue, Jul 24, 2018 at 09:07:03AM -0400, Mike Snitzer wrote: > True. We only ever support mapping the partitions ontop of > request-based multipath (via dm-linear volumes created by kpartx). > > > So, have you tested that request-based multipathing works on a > > partition _at all_? I'm not sure if partition mapping is done > > correctly here; we never remap the start of the request (nor bio, > > come to speak of it), so it looks as if we would be doing the wrong > > things here. > > > > Have you checked that partition remapping is done correctly? > > It clearly doesn't work. Not quite following why but... blk_insert_cloned_request seems to be missing a call to blk_partition_remap. Given that no one but dm-multipath uses this request clone insert helper, and people generally run multipath on the whole device this is a code path that is almost never exercised. From mboxrd@z Thu Jan 1 00:00:00 1970 From: hch@infradead.org (Christoph Hellwig) Date: Tue, 24 Jul 2018 10:42:41 -0700 Subject: data corruption with 'splt' workload to XFS on DM cache with its 3 underlying devices being on same NVMe device In-Reply-To: <20180724130703.GA30804@redhat.com> References: <20180723163357.GA29658@redhat.com> <20180724130703.GA30804@redhat.com> Message-ID: <20180724174241.GA828@infradead.org> On Tue, Jul 24, 2018@09:07:03AM -0400, Mike Snitzer wrote: > True. We only ever support mapping the partitions ontop of > request-based multipath (via dm-linear volumes created by kpartx). > > > So, have you tested that request-based multipathing works on a > > partition _at all_? I'm not sure if partition mapping is done > > correctly here; we never remap the start of the request (nor bio, > > come to speak of it), so it looks as if we would be doing the wrong > > things here. > > > > Have you checked that partition remapping is done correctly? > > It clearly doesn't work. Not quite following why but... blk_insert_cloned_request seems to be missing a call to blk_partition_remap. Given that no one but dm-multipath uses this request clone insert helper, and people generally run multipath on the whole device this is a code path that is almost never exercised.