From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 719AE2C99 for ; Thu, 4 Nov 2021 19:04:44 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id B349D61051; Thu, 4 Nov 2021 19:04:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636052683; bh=6QPcBULZTXdCSGAGAHS0TvJSZvMO/KqkGnLb73dsPBc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bv7jKp3Yw1Rdie9XZDWNK3pIPqQoPNhud+EqCebVCSNFnXX1tJKRugwxgw+L+OWGR 2MLp/jTRGzvo1NoqGoAE4h9SET6WwR2eC6KxGEbcMshVRiJ3shOzD+v3fRuOlCDV9R 9G84hJuxDUt0jNPNpbLWG5OuhVHMx1EBgq9VUuR/29TPkJQ2u2B/sSSO0SotyKedJk vIVOo9i23NlZDiCmEUONOL1Ve83kSVqtxk9oDKbsfMth7fdhjwVmAa4V9JJhr/fdzN 4WL/W9RmR5LhAyY6JcVhB45zjOxTxwGLojZm72rrw52Ey6bohVc7ZaZCNnE2bWDg9r QNnReKci3yYEQ== Date: Thu, 4 Nov 2021 12:04:43 -0700 From: "Darrick J. Wong" To: Dan Williams Cc: Christoph Hellwig , Eric Sandeen , Mike Snitzer , Ira Weiny , device-mapper development , linux-xfs , Linux NVDIMM , linux-s390 , linux-fsdevel , linux-erofs@lists.ozlabs.org, linux-ext4 , virtualization@lists.linux-foundation.org Subject: Re: futher decouple DAX from block devices Message-ID: <20211104190443.GK24333@magnolia> References: <20211018044054.1779424-1-hch@lst.de> <21ff4333-e567-2819-3ae0-6a2e83ec7ce6@sandeen.net> <20211104081740.GA23111@lst.de> <20211104173417.GJ2237511@magnolia> <20211104173559.GB31740@lst.de> Precedence: bulk X-Mailing-List: nvdimm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Nov 04, 2021 at 11:10:19AM -0700, Dan Williams wrote: > On Thu, Nov 4, 2021 at 10:36 AM Christoph Hellwig wrote: > > > > On Thu, Nov 04, 2021 at 10:34:17AM -0700, Darrick J. Wong wrote: > > > /me wonders, are block devices going away? Will mkfs.xfs have to learn > > > how to talk to certain chardevs? I guess jffs2 and others already do > > > that kind of thing... but I suppose I can wait for the real draft to > > > show up to ramble further. ;) > > > > Right now I've mostly been looking into the kernel side. An no, I > > do not expect /dev/pmem* to go away as you'll still need it for a > > not DAX aware file system and/or application (such as mkfs initially). > > > > But yes, just pointing mkfs to the chardev should be doable with very > > little work. We can point it to a regular file after all. > > Note that I've avoided implementing read/write fops for dax devices > partly out of concern for not wanting to figure out shared-mmap vs > write coherence issues, but also because of a bet with Dave Hansen > that device-dax not grow features like what happened to hugetlbfs. So > it would seem mkfs would need to switch to mmap I/O, or bite the > bullet and implement read/write fops in the driver. That ... would require a fair amount of userspace changes, though at least e2fsprogs has pluggable io drivers, which would make mmapping a character device not too awful. xfsprogs would be another story -- porting the buffer cache mignt not be too bad, but mkfs and repair seem to issue pread/pwrite calls directly. Note that xfsprogs explicitly screens out chardevs. --D From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 365B6C433F5 for ; Thu, 4 Nov 2021 19:04:53 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A124161212 for ; Thu, 4 Nov 2021 19:04:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A124161212 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4HlY3l256zz2yQG for ; Fri, 5 Nov 2021 06:04:51 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=bv7jKp3Y; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=djwong@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=bv7jKp3Y; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4HlY3f65HTz2xXm for ; Fri, 5 Nov 2021 06:04:46 +1100 (AEDT) Received: by mail.kernel.org (Postfix) with ESMTPSA id B349D61051; Thu, 4 Nov 2021 19:04:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636052683; bh=6QPcBULZTXdCSGAGAHS0TvJSZvMO/KqkGnLb73dsPBc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bv7jKp3Yw1Rdie9XZDWNK3pIPqQoPNhud+EqCebVCSNFnXX1tJKRugwxgw+L+OWGR 2MLp/jTRGzvo1NoqGoAE4h9SET6WwR2eC6KxGEbcMshVRiJ3shOzD+v3fRuOlCDV9R 9G84hJuxDUt0jNPNpbLWG5OuhVHMx1EBgq9VUuR/29TPkJQ2u2B/sSSO0SotyKedJk vIVOo9i23NlZDiCmEUONOL1Ve83kSVqtxk9oDKbsfMth7fdhjwVmAa4V9JJhr/fdzN 4WL/W9RmR5LhAyY6JcVhB45zjOxTxwGLojZm72rrw52Ey6bohVc7ZaZCNnE2bWDg9r QNnReKci3yYEQ== Date: Thu, 4 Nov 2021 12:04:43 -0700 From: "Darrick J. Wong" To: Dan Williams Subject: Re: futher decouple DAX from block devices Message-ID: <20211104190443.GK24333@magnolia> References: <20211018044054.1779424-1-hch@lst.de> <21ff4333-e567-2819-3ae0-6a2e83ec7ce6@sandeen.net> <20211104081740.GA23111@lst.de> <20211104173417.GJ2237511@magnolia> <20211104173559.GB31740@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux NVDIMM , Mike Snitzer , linux-s390 , linux-erofs@lists.ozlabs.org, Eric Sandeen , virtualization@lists.linux-foundation.org, linux-xfs , device-mapper development , linux-fsdevel , linux-ext4 , Ira Weiny , Christoph Hellwig Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" On Thu, Nov 04, 2021 at 11:10:19AM -0700, Dan Williams wrote: > On Thu, Nov 4, 2021 at 10:36 AM Christoph Hellwig wrote: > > > > On Thu, Nov 04, 2021 at 10:34:17AM -0700, Darrick J. Wong wrote: > > > /me wonders, are block devices going away? Will mkfs.xfs have to learn > > > how to talk to certain chardevs? I guess jffs2 and others already do > > > that kind of thing... but I suppose I can wait for the real draft to > > > show up to ramble further. ;) > > > > Right now I've mostly been looking into the kernel side. An no, I > > do not expect /dev/pmem* to go away as you'll still need it for a > > not DAX aware file system and/or application (such as mkfs initially). > > > > But yes, just pointing mkfs to the chardev should be doable with very > > little work. We can point it to a regular file after all. > > Note that I've avoided implementing read/write fops for dax devices > partly out of concern for not wanting to figure out shared-mmap vs > write coherence issues, but also because of a bet with Dave Hansen > that device-dax not grow features like what happened to hugetlbfs. So > it would seem mkfs would need to switch to mmap I/O, or bite the > bullet and implement read/write fops in the driver. That ... would require a fair amount of userspace changes, though at least e2fsprogs has pluggable io drivers, which would make mmapping a character device not too awful. xfsprogs would be another story -- porting the buffer cache mignt not be too bad, but mkfs and repair seem to issue pread/pwrite calls directly. Note that xfsprogs explicitly screens out chardevs. --D From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14025C433F5 for ; Thu, 4 Nov 2021 19:05:00 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A8BBD61051 for ; Thu, 4 Nov 2021 19:04:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A8BBD61051 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-321-aCvpWiuwN4640QcwJIgxLQ-1; Thu, 04 Nov 2021 15:04:57 -0400 X-MC-Unique: aCvpWiuwN4640QcwJIgxLQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A520F800053; Thu, 4 Nov 2021 19:04:52 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 578BF196AE; Thu, 4 Nov 2021 19:04:52 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id C003D4EA2F; Thu, 4 Nov 2021 19:04:51 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1A4J4nAr015096 for ; Thu, 4 Nov 2021 15:04:49 -0400 Received: by smtp.corp.redhat.com (Postfix) id 779B251E1; Thu, 4 Nov 2021 19:04:49 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7078E51E4 for ; Thu, 4 Nov 2021 19:04:46 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 91029802A5E for ; Thu, 4 Nov 2021 19:04:46 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-45-x2Hb12ZuOae2G9bmOf38qw-1; Thu, 04 Nov 2021 15:04:45 -0400 X-MC-Unique: x2Hb12ZuOae2G9bmOf38qw-1 Received: by mail.kernel.org (Postfix) with ESMTPSA id B349D61051; Thu, 4 Nov 2021 19:04:43 +0000 (UTC) Date: Thu, 4 Nov 2021 12:04:43 -0700 From: "Darrick J. Wong" To: Dan Williams Message-ID: <20211104190443.GK24333@magnolia> References: <20211018044054.1779424-1-hch@lst.de> <21ff4333-e567-2819-3ae0-6a2e83ec7ce6@sandeen.net> <20211104081740.GA23111@lst.de> <20211104173417.GJ2237511@magnolia> <20211104173559.GB31740@lst.de> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-loop: dm-devel@redhat.com Cc: Linux NVDIMM , Mike Snitzer , linux-s390 , linux-erofs@lists.ozlabs.org, Eric Sandeen , virtualization@lists.linux-foundation.org, linux-xfs , device-mapper development , linux-fsdevel , linux-ext4 , Ira Weiny , Christoph Hellwig Subject: Re: [dm-devel] futher decouple DAX from block devices X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Nov 04, 2021 at 11:10:19AM -0700, Dan Williams wrote: > On Thu, Nov 4, 2021 at 10:36 AM Christoph Hellwig wrote: > > > > On Thu, Nov 04, 2021 at 10:34:17AM -0700, Darrick J. Wong wrote: > > > /me wonders, are block devices going away? Will mkfs.xfs have to learn > > > how to talk to certain chardevs? I guess jffs2 and others already do > > > that kind of thing... but I suppose I can wait for the real draft to > > > show up to ramble further. ;) > > > > Right now I've mostly been looking into the kernel side. An no, I > > do not expect /dev/pmem* to go away as you'll still need it for a > > not DAX aware file system and/or application (such as mkfs initially). > > > > But yes, just pointing mkfs to the chardev should be doable with very > > little work. We can point it to a regular file after all. > > Note that I've avoided implementing read/write fops for dax devices > partly out of concern for not wanting to figure out shared-mmap vs > write coherence issues, but also because of a bet with Dave Hansen > that device-dax not grow features like what happened to hugetlbfs. So > it would seem mkfs would need to switch to mmap I/O, or bite the > bullet and implement read/write fops in the driver. That ... would require a fair amount of userspace changes, though at least e2fsprogs has pluggable io drivers, which would make mmapping a character device not too awful. xfsprogs would be another story -- porting the buffer cache mignt not be too bad, but mkfs and repair seem to issue pread/pwrite calls directly. Note that xfsprogs explicitly screens out chardevs. --D -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel