From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B02B7210FC0A8 for ; Mon, 27 Aug 2018 09:07:46 -0700 (PDT) Date: Mon, 27 Aug 2018 18:07:44 +0200 From: Jan Kara Subject: Snapshot target and DAX-capable devices Message-ID: <20180827160744.GE4002@quack2.suse.cz> MIME-Version: 1.0 Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: linux-nvdimm@lists.01.org Cc: Mike Snitzer , dm-devel@redhat.com, linux-fsdevel@vger.kernel.org List-ID: Hi, I've been analyzing why fstest generic/081 fails when the backing device is capable of DAX. The problem boils down to the failure of: lvm vgcreate -f vg0 /dev/pmem0 lvm lvcreate -L 128M -n lv0 vg0 lvm lvcreate -s -L 4M -n snap0 vg0/lv0 The last command fails like: device-mapper: reload ioctl on (253:0) failed: Invalid argument Failed to lock logical volume vg0/lv0. Aborting. Manual intervention required. And the core of the problem is that volume vg0/lv0 is originally of DM_TYPE_DAX_BIO_BASED type but when the snapshot gets created, we try to switch it to DM_TYPE_BIO_BASED because now the device stops supporting DAX. The problem seems to be introduced by Ross' commit dbc626597 "dm: prevent DAX mounts if not supported". The question is whether / how this should be fixed. The current inability to create snapshots of DAX-capable devices looks weird and the cryptic failure makes it even worse (it took me quite a while to understand what is failing and why). OTOH I see the rationale behind Ross' change as well. Honza -- Jan Kara SUSE Labs, CR _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:36456 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726958AbeH0Ty7 (ORCPT ); Mon, 27 Aug 2018 15:54:59 -0400 Date: Mon, 27 Aug 2018 18:07:44 +0200 From: Jan Kara To: linux-nvdimm@lists.01.org Cc: Ross Zwisler , dm-devel@redhat.com, Mike Snitzer , linux-fsdevel@vger.kernel.org, Toshi Kani , Dan Williams Subject: Snapshot target and DAX-capable devices Message-ID: <20180827160744.GE4002@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi, I've been analyzing why fstest generic/081 fails when the backing device is capable of DAX. The problem boils down to the failure of: lvm vgcreate -f vg0 /dev/pmem0 lvm lvcreate -L 128M -n lv0 vg0 lvm lvcreate -s -L 4M -n snap0 vg0/lv0 The last command fails like: device-mapper: reload ioctl on (253:0) failed: Invalid argument Failed to lock logical volume vg0/lv0. Aborting. Manual intervention required. And the core of the problem is that volume vg0/lv0 is originally of DM_TYPE_DAX_BIO_BASED type but when the snapshot gets created, we try to switch it to DM_TYPE_BIO_BASED because now the device stops supporting DAX. The problem seems to be introduced by Ross' commit dbc626597 "dm: prevent DAX mounts if not supported". The question is whether / how this should be fixed. The current inability to create snapshots of DAX-capable devices looks weird and the cryptic failure makes it even worse (it took me quite a while to understand what is failing and why). OTOH I see the rationale behind Ross' change as well. Honza -- Jan Kara SUSE Labs, CR From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Snapshot target and DAX-capable devices Date: Mon, 27 Aug 2018 18:07:44 +0200 Message-ID: <20180827160744.GE4002@quack2.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Cc: Mike Snitzer , dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: dm-devel.ids Hi, I've been analyzing why fstest generic/081 fails when the backing device is capable of DAX. The problem boils down to the failure of: lvm vgcreate -f vg0 /dev/pmem0 lvm lvcreate -L 128M -n lv0 vg0 lvm lvcreate -s -L 4M -n snap0 vg0/lv0 The last command fails like: device-mapper: reload ioctl on (253:0) failed: Invalid argument Failed to lock logical volume vg0/lv0. Aborting. Manual intervention required. And the core of the problem is that volume vg0/lv0 is originally of DM_TYPE_DAX_BIO_BASED type but when the snapshot gets created, we try to switch it to DM_TYPE_BIO_BASED because now the device stops supporting DAX. The problem seems to be introduced by Ross' commit dbc626597 "dm: prevent DAX mounts if not supported". The question is whether / how this should be fixed. The current inability to create snapshots of DAX-capable devices looks weird and the cryptic failure makes it even worse (it took me quite a while to understand what is failing and why). OTOH I see the rationale behind Ross' change as well. Honza -- Jan Kara SUSE Labs, CR