linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: Naohiro Aota <naohiro.aota@wdc.com>,
	linux-btrfs@vger.kernel.org, dsterba@suse.com
Cc: hare@suse.com, linux-fsdevel@vger.kernel.org,
	Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@infradead.org>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v13 22/42] btrfs: split ordered extent when bio is sent
Date: Fri, 22 Jan 2021 10:22:10 -0500	[thread overview]
Message-ID: <e265540c-9613-9473-f7e6-0f55d455b18e@toxicpanda.com> (raw)
In-Reply-To: <25b86d9571b1af386f1711d0d0ae626ae6a86b35.1611295439.git.naohiro.aota@wdc.com>

On 1/22/21 1:21 AM, Naohiro Aota wrote:
> For a zone append write, the device decides the location the data is
> written to. Therefore we cannot ensure that two bios are written
> consecutively on the device. In order to ensure that a ordered extent maps
> to a contiguous region on disk, we need to maintain a "one bio == one
> ordered extent" rule.
> 
> This commit implements the splitting of an ordered extent and extent map
> on bio submission to adhere to the rule.
> 
> [testbot] made extract_ordered_extent static
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
> ---
>   fs/btrfs/inode.c        | 95 +++++++++++++++++++++++++++++++++++++++++
>   fs/btrfs/ordered-data.c | 85 ++++++++++++++++++++++++++++++++++++
>   fs/btrfs/ordered-data.h |  2 +
>   3 files changed, 182 insertions(+)
> 
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index 2e1c1f37b3f6..ab97d4349515 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -2217,6 +2217,92 @@ static blk_status_t btrfs_submit_bio_start(struct inode *inode, struct bio *bio,
>   	return btrfs_csum_one_bio(BTRFS_I(inode), bio, 0, 0);
>   }
>   
> +static blk_status_t extract_ordered_extent(struct btrfs_inode *inode,
> +					   struct bio *bio, loff_t file_offset)
> +{
> +	struct btrfs_ordered_extent *ordered;
> +	struct extent_map *em = NULL, *em_new = NULL;
> +	struct extent_map_tree *em_tree = &inode->extent_tree;
> +	u64 start = (u64)bio->bi_iter.bi_sector << SECTOR_SHIFT;
> +	u64 len = bio->bi_iter.bi_size;
> +	u64 end = start + len;
> +	u64 ordered_end;
> +	u64 pre, post;
> +	int ret = 0;
> +
> +	ordered = btrfs_lookup_ordered_extent(inode, file_offset);
> +	if (WARN_ON_ONCE(!ordered))
> +		return BLK_STS_IOERR;
> +
> +	/* No need to split */
> +	if (ordered->disk_num_bytes == len)
> +		goto out;
> +
> +	/* We cannot split once end_bio'd ordered extent */
> +	if (WARN_ON_ONCE(ordered->bytes_left != ordered->disk_num_bytes)) {
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	/* We cannot split a compressed ordered extent */
> +	if (WARN_ON_ONCE(ordered->disk_num_bytes != ordered->num_bytes)) {
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	/* We cannot split a waited ordered extent */
> +	if (WARN_ON_ONCE(wq_has_sleeper(&ordered->wait))) {
> +		ret = -EINVAL;
> +		goto out;
> +	}

How is this not a problem?  We can have any arbitrary waiter on an ordered 
extent at any given time?  Write to an area with memory pressure and then fsync 
immediately so we have to wait on an ordered extent that may need to be split, 
bam you get this warning and fail to write out.  This seems like a bad side effect.

> +
> +	ordered_end = ordered->disk_bytenr + ordered->disk_num_bytes;
> +	/* bio must be in one ordered extent */
> +	if (WARN_ON_ONCE(start < ordered->disk_bytenr || end > ordered_end)) {
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	/* Checksum list should be empty */
> +	if (WARN_ON_ONCE(!list_empty(&ordered->list))) {
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	pre = start - ordered->disk_bytenr;
> +	post = ordered_end - end;
> +
> +	ret = btrfs_split_ordered_extent(ordered, pre, post);
> +	if (ret)
> +		goto out;
> +
> +	read_lock(&em_tree->lock);
> +	em = lookup_extent_mapping(em_tree, ordered->file_offset, len);
> +	if (!em) {
> +		read_unlock(&em_tree->lock);
> +		ret = -EIO;
> +		goto out;
> +	}
> +	read_unlock(&em_tree->lock);
> +
> +	ASSERT(!test_bit(EXTENT_FLAG_COMPRESSED, &em->flags));
> +	em_new = create_io_em(inode, em->start + pre, len,
> +			      em->start + pre, em->block_start + pre, len,
> +			      len, len, BTRFS_COMPRESS_NONE,
> +			      BTRFS_ORDERED_REGULAR);

This bit confuses me, the io_em is just so we have a mapping to an area that's 
being written to, and this is created at ordered extent time.  I get why we need 
to split up the ordered extent, but the existing io_em should be fine, right? 
Thanks,

Josef

  reply	other threads:[~2021-01-22 15:24 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22  6:21 [PATCH v13 00/42] btrfs: zoned block device support Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 01/42] block: add bio_add_zone_append_page Naohiro Aota
2021-01-23  2:50   ` Chaitanya Kulkarni
2021-01-23  3:08   ` Chaitanya Kulkarni
2021-01-25 17:31   ` Johannes Thumshirn
2021-01-22  6:21 ` [PATCH v13 02/42] iomap: support REQ_OP_ZONE_APPEND Naohiro Aota
2021-01-23  2:56   ` Chaitanya Kulkarni
2021-01-22  6:21 ` [PATCH v13 03/42] btrfs: defer loading zone info after opening trees Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 04/42] btrfs: use regular SB location on emulated zoned mode Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 05/42] btrfs: release path before calling into btrfs_load_block_group_zone_info Naohiro Aota
2021-01-22 14:57   ` Josef Bacik
2021-01-22  6:21 ` [PATCH v13 06/42] btrfs: do not load fs_info->zoned from incompat flag Naohiro Aota
2021-01-22 14:58   ` Josef Bacik
2021-01-22  6:21 ` [PATCH v13 07/42] btrfs: disallow fitrim in ZONED mode Naohiro Aota
2021-01-22 14:59   ` Josef Bacik
2021-01-22  6:21 ` [PATCH v13 08/42] btrfs: allow zoned mode on non-zoned block devices Naohiro Aota
2021-01-22 15:03   ` Josef Bacik
2021-01-22  6:21 ` [PATCH v13 09/42] btrfs: implement zoned chunk allocator Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 10/42] btrfs: verify device extent is aligned to zone Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 11/42] btrfs: load zone's allocation offset Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 12/42] btrfs: calculate allocation offset for conventional zones Naohiro Aota
2021-01-22 15:07   ` Josef Bacik
2021-01-22  6:21 ` [PATCH v13 13/42] btrfs: track unusable bytes for zones Naohiro Aota
2021-01-22 15:11   ` Josef Bacik
2021-01-25 10:37     ` Johannes Thumshirn
2021-01-25 12:08       ` Johannes Thumshirn
2021-01-22  6:21 ` [PATCH v13 14/42] btrfs: do sequential extent allocation in ZONED mode Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 15/42] btrfs: redirty released extent buffers " Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 16/42] btrfs: advance allocation pointer after tree log node Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 17/42] btrfs: enable to mount ZONED incompat flag Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 18/42] btrfs: reset zones of unused block groups Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 19/42] btrfs: extract page adding function Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 20/42] btrfs: use bio_add_zone_append_page for zoned btrfs Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 21/42] btrfs: handle REQ_OP_ZONE_APPEND as writing Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 22/42] btrfs: split ordered extent when bio is sent Naohiro Aota
2021-01-22 15:22   ` Josef Bacik [this message]
2021-01-25  8:56     ` Johannes Thumshirn
2021-01-25  9:02     ` Johannes Thumshirn
2021-01-22  6:21 ` [PATCH v13 23/42] btrfs: check if bio spans across an ordered extent Naohiro Aota
2021-01-22 15:23   ` Josef Bacik
2021-01-22  6:21 ` [PATCH v13 24/42] btrfs: extend btrfs_rmap_block for specifying a device Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 25/42] btrfs: cache if block-group is on a sequential zone Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 26/42] btrfs: save irq flags when looking up an ordered extent Naohiro Aota
2021-01-22 15:24   ` Josef Bacik
2021-01-22  6:21 ` [PATCH v13 27/42] btrfs: use ZONE_APPEND write for ZONED btrfs Naohiro Aota
2021-01-22 15:29   ` Josef Bacik
2021-01-22  6:21 ` [PATCH v13 28/42] btrfs: enable zone append writing for direct IO Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 29/42] btrfs: introduce dedicated data write path for ZONED mode Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 30/42] btrfs: serialize meta IOs on " Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 31/42] btrfs: wait existing extents before truncating Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 32/42] btrfs: avoid async metadata checksum on ZONED mode Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 33/42] btrfs: mark block groups to copy for device-replace Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 34/42] btrfs: implement cloning for ZONED device-replace Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 35/42] btrfs: implement copying " Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 36/42] btrfs: support dev-replace in ZONED mode Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 37/42] btrfs: enable relocation " Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 38/42] btrfs: relocate block group to repair IO failure in ZONED Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 39/42] btrfs: split alloc_log_tree() Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 40/42] btrfs: extend zoned allocator to use dedicated tree-log block group Naohiro Aota
2021-01-22  6:21 ` [PATCH v13 41/42] btrfs: serialize log transaction on ZONED mode Naohiro Aota
2021-01-22 15:37   ` Josef Bacik
2021-01-22  6:21 ` [PATCH v13 42/42] btrfs: reorder log node allocation Naohiro Aota

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=e265540c-9613-9473-f7e6-0f55d455b18e@toxicpanda.com \
    --to=josef@toxicpanda.com \
    --cc=axboe@kernel.dk \
    --cc=darrick.wong@oracle.com \
    --cc=dsterba@suse.com \
    --cc=hare@suse.com \
    --cc=hch@infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=naohiro.aota@wdc.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).