From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-fsdevel@vger.kernel.org, willy@linux.intel.com,
jack@suse.cz, xfs@oss.sgi.com
Subject: Re: [PATCH 4/8] xfs: add DAX block zeroing support
Date: Mon, 6 Apr 2015 13:48:53 -0400 [thread overview]
Message-ID: <20150406174853.GB58965@bfoster.bfoster> (raw)
In-Reply-To: <1427194266-2885-5-git-send-email-david@fromorbit.com>
On Tue, Mar 24, 2015 at 09:51:02PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> Add initial support for DAX block zeroing operations to XFS. DAX
> cannot use buffered IO through the page cache for zeroing, nor do we
> need to issue IO for uncached block zeroing. In both cases, we can
> simply call out to the dax block zeroing function.
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
> fs/xfs/xfs_bmap_util.c | 23 +++++++++++++++++++----
> fs/xfs/xfs_file.c | 28 +++++++++++++++++-----------
> 2 files changed, 36 insertions(+), 15 deletions(-)
>
> diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
> index 1bd5393..d1fe432 100644
> --- a/fs/xfs/xfs_bmap_util.c
> +++ b/fs/xfs/xfs_bmap_util.c
> @@ -1133,14 +1133,29 @@ xfs_zero_remaining_bytes(
> break;
> ASSERT(imap.br_blockcount >= 1);
> ASSERT(imap.br_startoff == offset_fsb);
> + ASSERT(imap.br_startblock != DELAYSTARTBLOCK);
> +
> + if (imap.br_startblock == HOLESTARTBLOCK ||
> + imap.br_state == XFS_EXT_UNWRITTEN) {
> + /* skip the entire extent */
> + lastoffset = XFS_FSB_TO_B(mp, imap.br_startoff +
> + imap.br_blockcount) - 1;
> + continue;
> + }
> +
> lastoffset = XFS_FSB_TO_B(mp, imap.br_startoff + 1) - 1;
> if (lastoffset > endoff)
> lastoffset = endoff;
> - if (imap.br_startblock == HOLESTARTBLOCK)
> - continue;
> - ASSERT(imap.br_startblock != DELAYSTARTBLOCK);
> - if (imap.br_state == XFS_EXT_UNWRITTEN)
> +
> + /* DAX can just zero the backing device directly */
> + if (IS_DAX(VFS_I(ip))) {
> + error = dax_zero_page_range(VFS_I(ip), offset,
> + lastoffset - offset + 1,
> + xfs_get_blocks_dax);
> + if (error)
> + return error;
> continue;
> + }
>
> error = xfs_buf_read_uncached(XFS_IS_REALTIME_INODE(ip) ?
> mp->m_rtdev_targp : mp->m_ddev_targp,
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index a4c882e..94713c2 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -97,7 +97,8 @@ xfs_iozero(
> {
> struct page *page;
> struct address_space *mapping;
> - int status;
> + int status = 0;
> +
>
> mapping = VFS_I(ip)->i_mapping;
> do {
> @@ -109,20 +110,25 @@ xfs_iozero(
> if (bytes > count)
> bytes = count;
>
> - status = pagecache_write_begin(NULL, mapping, pos, bytes,
> - AOP_FLAG_UNINTERRUPTIBLE,
> - &page, &fsdata);
> - if (status)
> - break;
> + if (IS_DAX(VFS_I(ip)))
> + dax_zero_page_range(VFS_I(ip), pos, bytes,
> + xfs_get_blocks_dax);
xfs_get_blocks_dax() isn't defined yet. We should also probably error
check here, yes?
A nit... If we have to update this patch, it would be nice to update the
comment above the function to adjust expectations with regard to the
suggestion that this always allocates blocks. If I follow the dax
codepath correctly, dax_zero_page_range() is a noop over holes or
unwritten blocks (not that it seems to matter for current callers).
> + else {
> + status = pagecache_write_begin(NULL, mapping, pos, bytes,
> + AOP_FLAG_UNINTERRUPTIBLE,
> + &page, &fsdata);
> + if (status)
> + break;
>
> - zero_user(page, offset, bytes);
> + zero_user(page, offset, bytes);
>
> - status = pagecache_write_end(NULL, mapping, pos, bytes, bytes,
> - page, fsdata);
> - WARN_ON(status <= 0); /* can't return less than zero! */
> + status = pagecache_write_end(NULL, mapping, pos, bytes,
> + bytes, page, fsdata);
> + WARN_ON(status <= 0); /* can't return less than zero! */
> + status = 0;
> + }
> pos += bytes;
> count -= bytes;
> - status = 0;
> } while (count);
>
> return (-status);
FWIW, that looks like a potential positive return code path
(write_begin)...
Brian
> --
> 2.0.0
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-04-06 17:49 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-24 10:50 [PATCH 0/8 v2] xfs: DAX support Dave Chinner
2015-03-24 10:50 ` [PATCH 1/8] xfs: mmap lock needs to be inside freeze protection Dave Chinner
2015-04-01 14:34 ` Jan Kara
2015-04-06 17:48 ` Brian Foster
2015-03-24 10:51 ` [PATCH 2/8] dax: don't abuse get_block mapping for endio callbacks Dave Chinner
2015-04-01 14:53 ` Jan Kara
2015-03-24 10:51 ` [PATCH 3/8] dax: expose __dax_fault for filesystems with locking constraints Dave Chinner
2015-04-01 15:07 ` Jan Kara
2015-03-24 10:51 ` [PATCH 4/8] xfs: add DAX block zeroing support Dave Chinner
2015-04-06 17:48 ` Brian Foster [this message]
2015-03-24 10:51 ` [PATCH 5/8] xfs: add DAX file operations support Dave Chinner
2015-03-24 12:08 ` Boaz Harrosh
2015-03-24 12:24 ` Boaz Harrosh
2015-03-24 21:17 ` Dave Chinner
2015-03-25 8:47 ` Boaz Harrosh
2015-04-06 17:49 ` Brian Foster
2015-04-16 8:29 ` Dave Chinner
2015-04-16 9:33 ` Boaz Harrosh
2015-04-16 11:47 ` Dave Chinner
2015-03-24 10:51 ` [PATCH 6/8] xfs: add DAX truncate support Dave Chinner
2015-04-06 17:49 ` Brian Foster
2015-03-24 10:51 ` [PATCH 7/8] xfs: add DAX IO path support Dave Chinner
2015-04-06 17:49 ` Brian Foster
2015-04-16 8:54 ` Dave Chinner
2015-03-24 10:51 ` [PATCH 8/8] xfs: add initial DAX support Dave Chinner
2015-03-24 12:52 ` Boaz Harrosh
2015-03-24 21:25 ` Dave Chinner
2015-03-25 9:14 ` Boaz Harrosh
2015-04-06 19:00 ` Brian Foster
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=20150406174853.GB58965@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=willy@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox