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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable 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 287FCC04E84 for ; Thu, 16 May 2019 01:48:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E90652087E for ; Thu, 16 May 2019 01:48:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="j9nGNhyM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726971AbfEPBqb (ORCPT ); Wed, 15 May 2019 21:46:31 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:35635 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726677AbfEPAWD (ORCPT ); Wed, 15 May 2019 20:22:03 -0400 Received: by mail-oi1-f194.google.com with SMTP id a132so1222196oib.2 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=jow1bqZBtOj6pBZb2K4Hta0iROQYOeEEW47z99yXzT0jr+NTA/T9Ce+OwR6XHLVM0h UVsEvoz4gDo/TOOPwqdSNmA/NRq9xwBwxGgHzg/ZH6fADs7Yiw+8uaHZBbRS8ritWZs5 cFrmwM6qKdKx8Q8CI8xeV6Cu/qgj40TRNvM4pX+Y7vSxhNHZHTRlio9HqkIWY5mK+9RY P/9yjVCRhoz2ZGaPFzhg4kN+dhzxlioP9xhr3RNCbKVbTNJWiB0NH3VUfLNV33K6RkdM wT87Eed2R9ezzqEEoFHDSdybabEHE+zi9YnLsf2KACkbrYjTgXKmEdRP0AihHtAOxqSs icmQ== X-Gm-Message-State: APjAAAVWm9LbQNZzRh86o0lAkTJ2LFRavVhCFQ3/Sa/HqWLn+hHg6NTL Ne6tp7q0QFcnwHQCxyBbTM5Yi/JY7JCHcqESIIZarZSO X-Google-Smtp-Source: APXvYqzDrmQi77dAWBNc07ndDu3T5pa6iN0pcVHtAZNxLtfjwvQPS0Zb7sMkMpyK1B3ioBtGGZnPjQ/C8y0NssMQmSA= 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: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@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.