Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp55670yba; Wed, 15 May 2019 18:50:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqweZZLGIr92zMocnxBCrnfGlAY20qqDwTv4x5q4lgQsCZfUKR5ouSt36+VHAi6qyFpYwh6U X-Received: by 2002:a63:b70f:: with SMTP id t15mr45225392pgf.351.1557971453308; Wed, 15 May 2019 18:50:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557971453; cv=none; d=google.com; s=arc-20160816; b=AjQtY6k6S9eC71nRJqDKx6C79fQUaC3Wz8dswy5+fR7NArgCMaj9w6SoE+0JiqCFaX ZpDxcpLO8MIesPk5ngwChZVl/O1V51fQMMK5RIX8gnamQ50U8kdKVuCkbt4xeXFkZ0QN rlw3nig6RB030vv1trD9CzmOkqwAimBRa7gOII2m+7p/LZdVwiAwpkKwLLKsROkyJCvr PhSBuHhvqQcbca0Dn20KuM3/EXnWzgWnxvkbCYxY5NUydgQhvibIG+v5e3qPSA84fNXq ygax5V3Um5kxW11Onhs97zuTC4CT0nOBu28FOO7laGE5rp9/4FLQKbmsyin70hIjz/Xy g+pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=bobcIcGI2hoSe5dAxap34CNUn9LKnTkS03oUmV7h0q4=; b=k9/J7Y2pwc+E1wojd9texf+qmrBW7sK08OUzILgLrpVn6A2fUI5sAaMm5Bd8XtyvOd c5iRYxT/vj8v7D/agkPdIFMds5wAqt329Z4X64r8LGodlO0DOuKuTk9HEabBLZyN76CY r4J5hubMjUt6LLAUreAXqXr1qfuSCDcJMbE+ya/wwMh24dwqUVOtKQAKtfCifI3TFFzd y082+4yuk0WS2y6Xfqe7jvuNys6of/AkhoajvfWF2cnPLwEJK27VmePYHfZoh90P7XoM BXo7kMg8gvMihtGOVkMcuI6yft4g8kqKNAcoCXWgypjtCcK72T/MzJOBudLOuTEmT7TB j5vA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=j9nGNhyM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j23si3716070pff.159.2019.05.15.18.50.38; Wed, 15 May 2019 18:50:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=j9nGNhyM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727515AbfEPBqe (ORCPT + 99 others); Wed, 15 May 2019 21:46:34 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:39376 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726733AbfEPAWD (ORCPT ); Wed, 15 May 2019 20:22:03 -0400 Received: by mail-oi1-f195.google.com with SMTP id v2so1200024oie.6 for ; Wed, 15 May 2019 17:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bobcIcGI2hoSe5dAxap34CNUn9LKnTkS03oUmV7h0q4=; b=j9nGNhyMsOaTVud6KO3dskijFfmT2ZQWGqLP7vYr40RYrbZpP2ISfBY4/jbvgTXbHD PBNLGCVvSGEIW+pkvZWIknWRx7irtf13DgdR99Ie6/6xDxy1VgUpVBlwuK3ybEJWLqgW utTN/SrtWzEr/dIFr8r1RtV1Jsh3YspspkZIMQzCSJBi0BrKaoBFZs55FZ0kUQ+CSg3y cLNlzpERm8qRNJFebCDsd3GPaloqk3nhEzbkU4ir0yewDOVvjZvhY9NZ9QQfKgfHgQw3 Jf1vLci6RuObHmAw9PyVKzRBRDvCgYO0flvWfgK5uIBS1CIRxOGoy2HsIk/r+YmH4QgG GIkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bobcIcGI2hoSe5dAxap34CNUn9LKnTkS03oUmV7h0q4=; b=frxFidJUinNjz807bwzJlpH2vhIP8enY0nxAQuz8GnySw7uppZrgiv+YjmveIVT0Uh NLbFTIhwBZ1WpH+vbjb7YISdMysXogiG8jk7cX3OrkCwohZ6eZb625TArLAQDu9YjZn/ rSYmquQF13dqUePPnfqHftAXXdu/XJlpm8j3TFOfH46vrMdW98PGrj7DxTIe1wDYx1We fl8iFN0WvuElSIAI0JPnDtCFqi5ICjntSZg03qwHuddVB+kFvDDoiFuZgOhmfcFSiJnY 54aqQqR7bpfwNHjW5rkzwmREqxcE8gR8yKBo64mqmhehWWv2Xkh2XaBPAbLxeIlH74DS k9AQ== X-Gm-Message-State: APjAAAXg0T34AEoGIMVdGfBFqacogAZrr40UripYi+ExVeMH3Yo9KFUQ YXN9r/7AoyTS7LaHkNkNHUxrlyiwW+KGQTkRyi2BQA== X-Received: by 2002:aca:b641:: with SMTP id g62mr5885998oif.149.1557966122846; Wed, 15 May 2019 17:22:02 -0700 (PDT) MIME-Version: 1.0 References: <20190515192715.18000-1-vgoyal@redhat.com> <20190515192715.18000-13-vgoyal@redhat.com> In-Reply-To: <20190515192715.18000-13-vgoyal@redhat.com> From: Dan Williams Date: Wed, 15 May 2019 17:21:51 -0700 Message-ID: Subject: Re: [PATCH v2 12/30] dax: remove block device dependencies To: Vivek Goyal Cc: linux-fsdevel , Linux Kernel Mailing List , KVM list , linux-nvdimm , Steven Whitehouse , "Dr. David Alan Gilbert" , Stefan Hajnoczi , Miklos Szeredi Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 15, 2019 at 12:28 PM Vivek Goyal wrote: > > From: Stefan Hajnoczi > > Although struct dax_device itself is not tied to a block device, some > DAX code assumes there is a block device. Make block devices optional > by allowing bdev to be NULL in commonly used DAX APIs. > > When there is no block device: > * Skip the partition offset calculation in bdev_dax_pgoff() > * Skip the blkdev_issue_zeroout() optimization > > Note that more block device assumptions remain but I haven't reach those > code paths yet. > Is there a generic object that non-block-based filesystems reference for physical storage as a bdev stand-in? I assume "sector_t" is still the common type for addressing filesystem capacity? It just seems to me that we should stop pretending that the filesystem-dax facility requires block devices and try to move this functionality to generically use a dax device across all interfaces.