From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: jack@suse.cz, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: don't invalidate whole file on DAX read/write
Date: Wed, 3 Aug 2016 02:25:02 -0700 [thread overview]
Message-ID: <20160803092502.GA17891@infradead.org> (raw)
In-Reply-To: <1470181226-20935-1-git-send-email-david@fromorbit.com>
On Wed, Aug 03, 2016 at 09:40:26AM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> When we do DAX IO, we try to invalidate the entire page cache held
> on the file. This is incorrect as it will trash the entire mapping
> tree that now tracks dirty state in exceptional entries in the radix
> tree slots.
>
> What we are trying to do is remove cached pages (e.g from reads
> into holes) that sit in the radix tree over the range we are about
> to write to. Hence we should just limit the invalidation to the
> range we are about to overwrite.
Looks fine (for a broad defintion of "fine"):
Reviewed-by: Christoph Hellwig <hch@lst.de>
> + * XXX: This is racy against mmap, and there's nothing we can do about
> + * it. dax_do_io() should really do this invalidation internally as
> + * it will know if we've allocated over a holei for this specific IO and
> + * if so it needs to update the mapping tree and invalidate existing
> + * PTEs over the newly allocated range. Remove this invalidation when
> + * dax_do_io() is fixed up.
FYI, I've got a basically working version of an iomap based DAX I/O path
(still fails a few corner cases), and I'll see if I can add that to it.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-08-03 9:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-02 23:40 [PATCH] xfs: don't invalidate whole file on DAX read/write Dave Chinner
2016-08-03 9:25 ` Christoph Hellwig [this message]
2016-08-03 15:34 ` Jan Kara
2016-08-03 22:32 ` Dave Chinner
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=20160803092502.GA17891@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=xfs@oss.sgi.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 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.