From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: Adam Borowski <kilobyte@angband.pl>
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
marcin.slusarz@intel.com
Subject: Re: [PATCH v2 00/15] btrfs dax support
Date: Wed, 27 Mar 2019 18:26:35 -0500 [thread overview]
Message-ID: <20190327232635.zw4edleqwowxfzej@merlin> (raw)
In-Reply-To: <20190327201442.GA22587@angband.pl>
On 21:14 27/03, Adam Borowski wrote:
> On Tue, Mar 26, 2019 at 02:09:08PM -0500, Goldwyn Rodrigues wrote:
> > This patch set adds support for dax on the BTRFS filesystem.
>
> This patchset doesn't seem to support MAP_SYNC, which is the usual way to
> use (and detect) DAX. Basically, it requests for page faults to be
> synchronous -- ie, when a page fault returns, the mapping points to actual
> memory rather than to some buffer that'll be written back to the destination
> at some point in the future.
The translation (in different flags/returns) goes as follows
MAP_SYNC -> VM_SYNC -> VM_NEEDDSYNC.
So, when dax_iomap_fault() returns, it is handled through
dax_finish_sync_fault(). This is how all filesystems are doing it currently.
Refer patch 09/15.
>
> Also, not really understanding these parts of the kernel, I can't tell if
> the snapshots are atomic. Ie, while the kernel walks over pages to set
> mprotect flags, the process does two writes:
> RRRRRRRRRRRRRRRRRRRWWWWWWWWWWWWWWWWWWWWWW (R=ro W=rw)
> A B
> The write at A causes a page fault, which clones the page, CoWing it and
> letting the write into only one of the replicas. After this, write to B
> happens before the mprotect, thus goes into both replicas -- and despite
> the process having issued proper memory barriers, the other replica has
> B but not A. To fix this, earlier page faults can't get finalized until
> all mprotects are in place. (I'm writing this as a query rather than a
> problem report -- I'm an ignoramus here.)
When you initiate a snapshot, btrfs forces everything to CoW until
snapshot finishes. This guarantees all new allocations
are Cow, even if the extent is set to nocow. During this time, all
"writebacks" happen. We don't have writebacks in DAX, but we take this
opportunity to wrprotect the mmap'd pages.
For more details, refer to patch 15/15 in the series.
--
Goldwyn
next prev parent reply other threads:[~2019-03-27 23:26 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190326190301.32365-1-rgoldwyn@suse.de>
2019-03-26 19:02 ` [PATCH 01/15] btrfs: create a mount option for dax Goldwyn Rodrigues
2019-03-26 19:10 ` Matthew Wilcox
2019-03-27 11:00 ` Goldwyn Rodrigues
2019-03-27 12:00 ` Matthew Wilcox
2019-03-27 12:26 ` Goldwyn Rodrigues
2019-03-27 23:31 ` Goldwyn Rodrigues
2019-03-27 17:38 ` Adam Borowski
2019-03-28 14:49 ` David Sterba
2019-03-28 17:28 ` David Sterba
2019-03-28 17:57 ` Darrick J. Wong
2019-04-01 20:43 ` Goldwyn Rodrigues
2019-03-26 19:02 ` [PATCH 02/15] btrfs: Carve out btrfs_get_extent_map_write() out of btrfs_get_blocks_write() Goldwyn Rodrigues
2019-03-26 19:02 ` [PATCH 03/15] btrfs: basic dax read Goldwyn Rodrigues
2019-03-26 19:02 ` [PATCH 04/15] dax: Introduce IOMAP_F_COW for copy-on-write Goldwyn Rodrigues
2019-03-27 17:54 ` Darrick J. Wong
2019-03-27 18:58 ` Goldwyn Rodrigues
2019-03-28 14:45 ` Darrick J. Wong
2019-04-01 4:38 ` Dave Chinner
2019-04-01 21:41 ` Goldwyn Rodrigues
2019-04-01 23:06 ` Dave Chinner
2019-04-03 1:56 ` Goldwyn Rodrigues
2019-04-03 3:20 ` Dave Chinner
2019-04-07 7:26 ` Christoph Hellwig
2019-03-26 19:02 ` [PATCH 05/15] btrfs: return whether extent is nocow or not Goldwyn Rodrigues
2019-03-31 18:42 ` Nikolay Borisov
2019-03-26 19:02 ` [PATCH 06/15] btrfs: Rename __endio_write_update_ordered() to btrfs_update_ordered_extent() Goldwyn Rodrigues
2019-03-26 19:02 ` [PATCH 07/15] btrfs: add dax write support Goldwyn Rodrigues
2019-03-28 14:53 ` Darrick J. Wong
2019-04-01 20:39 ` Goldwyn Rodrigues
2019-03-26 19:02 ` [PATCH 08/15] dax: add dax_iomap_cow to copy a mmap page before writing Goldwyn Rodrigues
2019-03-28 15:41 ` Darrick J. Wong
2019-03-26 19:02 ` [PATCH 09/15] btrfs: add dax mmap support Goldwyn Rodrigues
2019-03-28 15:45 ` Darrick J. Wong
2019-03-26 19:02 ` [PATCH 10/15] btrfs: Add dax specific address_space_operations Goldwyn Rodrigues
2019-03-26 19:02 ` [PATCH 11/15] fs: dedup file range to use a compare function Goldwyn Rodrigues
2019-03-28 17:04 ` Darrick J. Wong
2019-04-01 20:36 ` Goldwyn Rodrigues
2019-03-26 19:02 ` [PATCH 12/15] btrfs: trace functions for btrfs_iomap_begin/end Goldwyn Rodrigues
2019-03-26 19:02 ` [PATCH 13/15] btrfs: handle dax page zeroing Goldwyn Rodrigues
2019-03-26 19:03 ` [PATCH 14/15] btrfs: Disable dax-based defrag and send Goldwyn Rodrigues
2019-03-26 19:03 ` [PATCH 15/15] btrfs: Writeprotect mmap pages on snapshot Goldwyn Rodrigues
2019-03-28 15:48 ` Darrick J. Wong
2019-03-26 19:09 ` [PATCH v2 00/15] btrfs dax support Goldwyn Rodrigues
2019-03-27 20:14 ` Adam Borowski
2019-03-27 23:26 ` Goldwyn Rodrigues [this message]
2019-03-28 10:24 ` [PATCH] btrfs: allow MAP_SYNC mmap Adam Borowski
2019-03-28 10:42 ` Adam Borowski
2019-04-01 20:08 ` Goldwyn Rodrigues
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=20190327232635.zw4edleqwowxfzej@merlin \
--to=rgoldwyn@suse.de \
--cc=kilobyte@angband.pl \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=marcin.slusarz@intel.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).