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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 334E6C32771 for ; Thu, 9 Jan 2020 11:25:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 141F22075D for ; Thu, 9 Jan 2020 11:25:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730604AbgAILZN (ORCPT ); Thu, 9 Jan 2020 06:25:13 -0500 Received: from mx2.suse.de ([195.135.220.15]:43420 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730565AbgAILZN (ORCPT ); Thu, 9 Jan 2020 06:25:13 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 947B96A4CE; Thu, 9 Jan 2020 11:24:47 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 1FABF1E0798; Thu, 9 Jan 2020 12:24:47 +0100 (CET) Date: Thu, 9 Jan 2020 12:24:47 +0100 From: Jan Kara To: Dan Williams Cc: Vivek Goyal , "Darrick J. Wong" , Christoph Hellwig , Dave Chinner , Miklos Szeredi , linux-nvdimm , Linux Kernel Mailing List , "Dr. David Alan Gilbert" , virtio-fs@redhat.com, Stefan Hajnoczi , linux-fsdevel Subject: Re: [PATCH 01/19] dax: remove block device dependencies Message-ID: <20200109112447.GG27035@quack2.suse.cz> References: <20191216181014.GA30106@redhat.com> <20200107125159.GA15745@infradead.org> <20200107170731.GA472641@magnolia> <20200107180101.GC15920@redhat.com> <20200107183307.GD15920@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue 07-01-20 10:49:55, Dan Williams wrote: > On Tue, Jan 7, 2020 at 10:33 AM Vivek Goyal wrote: > > W.r.t partitioning, bdev_dax_pgoff() seems to be the pain point where > > dax code refers back to block device to figure out partition offset in > > dax device. If we create a dax object corresponding to "struct block_device" > > and store sector offset in that, then we could pass that object to dax > > code and not worry about referring back to bdev. I have written some > > proof of concept code and called that object "dax_handle". I can post > > that code if there is interest. > > I don't think it's worth it in the end especially considering > filesystems are looking to operate on /dev/dax devices directly and > remove block entanglements entirely. > > > IMHO, it feels useful to be able to partition and use a dax capable > > block device in same way as non-dax block device. It will be really > > odd to think that if filesystem is on /dev/pmem0p1, then dax can't > > be enabled but if filesystem is on /dev/mapper/pmem0p1, then dax > > will work. > > That can already happen today. If you do not properly align the > partition then dax operations will be disabled. This proposal just > extends that existing failure domain to make all partitions fail to > support dax. Well, I have some sympathy with the sysadmin that has /dev/pmem0 device, decides to create partitions on it for whatever (possibly misguided) reason and then ponders why the hell DAX is not working? And PAGE_SIZE partition alignment is so obvious and widespread that I don't count it as a realistic error case sysadmins would be pondering about currently. So I'd find two options reasonably consistent: 1) Keep status quo where partitions are created and support DAX. 2) Stop partition creation altogether, if anyones wants to split pmem device further, he can use dm-linear for that (i.e., kpartx). But I'm not sure if the ship hasn't already sailed for option 2) to be feasible without angry users and Linus reverting the change. Honza -- Jan Kara SUSE Labs, CR