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.3 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 60D4AC33CB1 for ; Wed, 15 Jan 2020 09:03:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3B709222C3 for ; Wed, 15 Jan 2020 09:03:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729210AbgAOJDR (ORCPT ); Wed, 15 Jan 2020 04:03:17 -0500 Received: from mx2.suse.de ([195.135.220.15]:33500 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726513AbgAOJDR (ORCPT ); Wed, 15 Jan 2020 04:03:17 -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 063F3AC6E; Wed, 15 Jan 2020 09:03:13 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 3EAEA1E0CBC; Wed, 15 Jan 2020 10:03:06 +0100 (CET) Date: Wed, 15 Jan 2020 10:03:06 +0100 From: Jan Kara To: Vivek Goyal Cc: Dan Williams , Jan Kara , "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 , Jeff Moyer Subject: Re: [PATCH 01/19] dax: remove block device dependencies Message-ID: <20200115090306.GA31450@quack2.suse.cz> References: <20200107180101.GC15920@redhat.com> <20200107183307.GD15920@redhat.com> <20200109112447.GG27035@quack2.suse.cz> <20200114203138.GA3145@redhat.com> <20200114212805.GB3145@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200114212805.GB3145@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 14-01-20 16:28:05, Vivek Goyal wrote: > On Tue, Jan 14, 2020 at 12:39:00PM -0800, Dan Williams wrote: > > I think we should at least try to delete the partition support and see > > if anyone screams. Have a module option to revert the behavior so > > people are not stuck waiting for the revert to land, but if it stays > > quiet then we're in a better place with that support pushed out of the > > dax core. > > Hi Dan, > > So basically keep partition support code just that disable it by default > and it is enabled by some knob say kernel command line option/module > option. > > At what point of time will we remove that code completely. I mean what > if people scream after two kernel releases, after we have removed the > code. > > Also, from distribution's perspective, we might not hear from our > customers for a very long time (till we backport that code in to > existing releases or release this new code in next major release). From > that view point I will not like to break existing user visible behavior. > > How bad it is to keep partition support around. To me it feels reasonaly > simple where we just have to store offset into dax device into another > dax object and pass that object around (instead of dax_device). If that's > the case, I am not sure why to even venture into a direction where some > user's setup might be broken. > > Also from an application perspective, /dev/pmem is a block device, so it > should behave like a block device, (including kernel partition table support). > From that view, dax looks like just an additional feature of that device > which can be enabled by passing option "-o dax". Well, not all block devices are partitionable. For example cdroms are standard block devices but partitioning does not run for them. Similarly device mapper devices are block devices but not partitioned. So there is some precedens in not doing partitioning for some types of block devices. For the rest I agree that kernels where pmem devices are partitionable have shipped in enterprise distros and are going to be supported (and used) for 5-10 years before users decide to move on to something newer - at which point we'll only find out whether someone used the feature or not. So deprecation is going to be somewhat interesting. On the other hand clever udev rule that detects partition table on pmem device and uses kpartx to partition these devices (like what happens e.g. for dm-multipath devices) could possibly be used as a replacement for kernel support so there's a way out of this... So I don't care too deeply about what the decision is going to be. Honza -- Jan Kara SUSE Labs, CR