From: Dave Chinner <email@example.com> To: Boaz Harrosh <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, Alexander Viro <email@example.com>, "Darrick J. Wong" <firstname.lastname@example.org>, Dan Williams <email@example.com>, Christoph Hellwig <firstname.lastname@example.org>, "Theodore Y. Ts'o" <email@example.com>, Jan Kara <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH 0/5] Enable per-file/directory DAX operations Date: Thu, 24 Oct 2019 18:34:46 +1100 [thread overview] Message-ID: <20191024073446.GA4614@dread.disaster.area> (raw) In-Reply-To: <firstname.lastname@example.org> On Thu, Oct 24, 2019 at 05:31:13AM +0300, Boaz Harrosh wrote: > On 24/10/2019 01:13, Dave Chinner wrote: > > On Wed, Oct 23, 2019 at 04:09:50PM +0300, Boaz Harrosh wrote: > >> On 22/10/2019 14:21, Boaz Harrosh wrote: > >>> On 20/10/2019 18:59, email@example.com wrote: > >> Please explain the use case behind your model? > > > > No application changes needed to control whether they use DAX or > > not. It allows the admin to control the application behaviour > > completely, so they can turn off DAX if necessary. Applications are > > unaware of constraints that may prevent DAX from being used, and so > > admins need a mechanism to prevent DAX aware application from > > actually using DAX if the capability is present. > > > > e.g. given how slow some PMEM devices are when it comes to writing > > data, especially under extremely high concurrency, DAX is not > > necessarily a performance win for every application. Admins need a > > guaranteed method of turning off DAX in these situations - apps may > > not provide such a knob, or even be aware of a thing called DAX... > > > > Thank you Dave for explaining. Forgive my slowness. I now understand > your intention. > > But if so please address my first concern. That in the submitted implementation > you must set the flag-bit after the create of the file but before the write. > So exactly the above slow writes must always be DAX if I ever want the file > to be DAX accessed in the future. The on disk DAX flag is inherited from the parent directory at create time. Hence an admin only need to set it on the data directory of the application when first configuring it, and everything the app creates will be configured for DAX access automatically. Or, alternatively, mkfs sets the flag on the root dir so that everything in the filesystem uses DAX by default (through inheritance) unless the admin turns off the flag on a directory before it starts to be used or on a set of files after they have been created (because DAX causes problems)... So, yeah, there's another problem with the basic assertion that we only need to allow the on disk flag to be changed on zero length files: we actually want to be able to -clear- the DAX flag when the file has data attached to it, not just when it is an empty file... > What if, say in XFS when setting the DAX-bit we take all the three write-locks > same as a truncate. Then we check that there are no active page-cache mappings > ie. a single opener. Then allow to set the bit. Else return EBUISY. (file is in use) DAX doesn't have page cache mappings, so anything that relies on checking page cache state isn't going to work reliably. I also seem to recall that there was a need to take some vm level lock to really prevent page fault races, and that we can't safely take that in a safe combination with all the filesystem locks we need. Cheers, Dave. -- Dave Chinner firstname.lastname@example.org
next prev parent reply other threads:[~2019-10-24 7:34 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-20 15:59 ira.weiny 2019-10-20 15:59 ` [PATCH 1/5] fs/stat: Define DAX statx attribute ira.weiny 2019-10-22 11:32 ` Boaz Harrosh 2019-10-22 16:51 ` Ira Weiny 2019-10-20 15:59 ` [PATCH 2/5] fs/xfs: Isolate the physical DAX flag from effective ira.weiny 2019-10-21 0:26 ` Dave Chinner 2019-10-21 17:40 ` Ira Weiny 2019-10-20 15:59 ` [PATCH 3/5] fs/xfs: Separate functionality of xfs_inode_supports_dax() ira.weiny 2019-10-20 15:59 ` [PATCH 4/5] fs/xfs: Clean up DAX support check ira.weiny 2019-10-20 15:59 ` [PATCH 5/5] fs/xfs: Allow toggle of physical DAX flag ira.weiny 2019-10-21 0:45 ` Dave Chinner 2019-10-21 22:49 ` Ira Weiny 2019-10-21 23:46 ` Dave Chinner 2019-11-08 13:12 ` Jan Kara 2019-11-08 13:46 ` Jan Kara 2019-11-08 19:36 ` Ira Weiny 2019-11-11 16:07 ` Jan Kara 2019-11-11 23:54 ` Ira Weiny 2019-10-22 11:21 ` [PATCH 0/5] Enable per-file/directory DAX operations Boaz Harrosh 2019-10-23 13:09 ` Boaz Harrosh 2019-10-23 22:13 ` Dave Chinner 2019-10-24 2:31 ` Boaz Harrosh 2019-10-24 7:34 ` Dave Chinner [this message] 2019-10-24 14:05 ` Boaz Harrosh 2019-10-24 21:35 ` Dave Chinner 2019-10-24 23:29 ` Boaz Harrosh 2019-10-25 0:36 ` Dave Chinner 2019-10-25 1:15 ` Boaz Harrosh 2019-10-25 20:49 ` Ira Weiny 2019-10-27 22:10 ` Dave Chinner 2019-10-31 16:17 ` Ira Weiny 2019-11-01 22:47 ` Dave Chinner 2019-11-02 4:25 ` Dan Williams
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191024073446.GA4614@dread.disaster.area \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 0/5] Enable per-file/directory DAX operations' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.