Return-Path: Received: from mail-ot1-f68.google.com ([209.85.210.68]:46360 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725966AbeJRFmp (ORCPT ); Thu, 18 Oct 2018 01:42:45 -0400 Received: by mail-ot1-f68.google.com with SMTP id o21so27732239otb.13 for ; Wed, 17 Oct 2018 14:45:07 -0700 (PDT) MIME-Version: 1.0 References: <1539027169-23332-1-git-send-email-sandeen@sandeen.net> <20181011103636.GC9467@quack2.suse.cz> <5a8e54e8-4845-1c85-e4e9-0b9b551a9ce2@sandeen.net> <20181012082154.GB30154@lst.de> <116ef687-f23d-b45c-1b48-fd444b346719@sandeen.net> In-Reply-To: From: Dan Williams Date: Wed, 17 Oct 2018 14:44:55 -0700 Message-ID: Subject: Re: [PATCH 0/3] ext2, ext4, xfs: hard fail dax mount on unsupported devices To: jmoyer Cc: Eric Sandeen , zwisler@kernel.org, Christoph Hellwig , Jan Kara , linux-xfs , linux-ext4 , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-ext4-owner@vger.kernel.org List-ID: On Wed, Oct 17, 2018 at 2:31 PM Jeff Moyer wrote: > > Eric Sandeen writes: > > > I've been thinking about the per-inode stuff a bit, and while I don't know > > how to resolve some of the trickier issues, at least the expected behavior > > seems like something we can narrow down and specify. > > > > Because it's an on-disk flag (in xfs today, in any case) it seems that > > the only sane behavior to expect is either/or, i.e.: > > > > Mount option: All files always dax, per-inode flags ignored (or rejected) > > Per-inode: Mount option cannot be specified; only inodes explicitly flagged are dax > > > > Think about it; what would mount-option-plus-per-inode mean? We have > > no "negative" dax flag, so while mount-option-with-flag surely means > > "dax", what the heck does mount-option-without-flag mean, and how is it > > distinguishable from mount option only? > > > > I submit that flags can only have meaning w/o the fs-wide mount option > > enabled, so the question of "should we hard fail mount -o dax for devices > > that cannot support it" seems to be orthogonal to the per-inode question. > > > > i.e. mount -o dax really can only mean "I want dax on everything" and so > > again, I think we probably need to fail the mount if that can't be honored. > > I hate to even open up this can of worms, but what about killing the dax > mount option? > > To quote Christoph: > How does an application "make use of DAX"? What actual user visible > semantics are associated with a file that has this flag set? > > We're already talking about making caching decisions automatically, so > does DAX even mean anything at that point? If the storage and the file > system support it, enable it. > > From what we've seen so far, aplications want: > 1) to be able to make data persistent from userspace > For this, we have MAP_SYNC. > 2) to determine whether or not page cache will be used > For this, we have O_DIRECT for read/write access, and MAP_SYNC for > mmap access (and maybe a third option coming, we'll see). As Jan has said, it's not safe to assume that 'no page cache' is implied with MAP_SYNC. It's a side effect not a contract of the current implementation. > The only thing users gain from a mount option is the ability to turn OFF > dax. I suppose there might be a use case that wants this, but I'm not > aware of it. I think we're stuck with it as many scripts would break if it ever went completely away. However, we could mark it deprecated / ignored provided we had a way for applications to query and override if DAX is enabled. I also think it's important to keep separate the dax-mmap behavior from the dax-read/write behavior. dax-mmap is where an application would make different decisions if it can get a mapping without page cache, dax-read/write does not appear to have any justification to be advertised because the application would not do anything different whether that is present or not.