public inbox for linux-api@vger.kernel.org
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Nikolay Borisov <nborisov@suse.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com,
	linux-fsdevel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-api@vger.kernel.org
Subject: Re: [PATCH v10 03/14] btrfs: don't advance offset for compressed bios in btrfs_csum_one_bio()
Date: Fri, 20 Aug 2021 10:37:19 -0700	[thread overview]
Message-ID: <YR/oT2dXaU3pTJE+@relinquished.localdomain> (raw)
In-Reply-To: <b3517f65-a22b-7c08-536c-1b5fc7d68fab@suse.com>

On Fri, Aug 20, 2021 at 11:08:41AM +0300, Nikolay Borisov wrote:
> 
> 
> On 18.08.21 г. 0:06, Omar Sandoval wrote:
> > From: Omar Sandoval <osandov@fb.com>
> > 
> > btrfs_csum_one_bio() loops over each filesystem block in the bio while
> > keeping a cursor of its current logical position in the file in order to
> > look up the ordered extent to add the checksums to. However, this
> > doesn't make much sense for compressed extents, as a sector on disk does
> > not correspond to a sector of decompressed file data. It happens to work
> > because 1) the compressed bio always covers one ordered extent and 2)
> > the size of the bio is always less than the size of the ordered extent.
> > However, the second point will not always be true for encoded writes.
> > 
> > Let's add a boolean parameter to btrfs_csum_one_bio() to indicate that
> > it can assume that the bio only covers one ordered extent. Since we're
> > already changing the signature, let's get rid of the contig parameter
> > and make it implied by the offset parameter, similar to the change we
> > recently made to btrfs_lookup_bio_sums(). Additionally, let's rename
> > nr_sectors to blockcount to make it clear that it's the number of
> > filesystem blocks, not the number of 512-byte sectors.
> > 
> > Reviewed-by: Josef Bacik <josef@toxicpanda.com>
> > Signed-off-by: Omar Sandoval <osandov@fb.com>
> > ---
> >  fs/btrfs/compression.c |  5 +++--
> >  fs/btrfs/ctree.h       |  2 +-
> >  fs/btrfs/file-item.c   | 35 ++++++++++++++++-------------------
> >  fs/btrfs/inode.c       |  8 ++++----
> >  4 files changed, 24 insertions(+), 26 deletions(-)
> > 
> > diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
> > index 7869ad12bc6e..e645b3c2f09a 100644
> > --- a/fs/btrfs/compression.c
> > +++ b/fs/btrfs/compression.c
> > @@ -480,7 +480,8 @@ blk_status_t btrfs_submit_compressed_write(struct btrfs_inode *inode, u64 start,
> >  			BUG_ON(ret); /* -ENOMEM */
> >  
> >  			if (!skip_sum) {
> > -				ret = btrfs_csum_one_bio(inode, bio, start, 1);
> > +				ret = btrfs_csum_one_bio(inode, bio, start,
> > +							 true);
> >  				BUG_ON(ret); /* -ENOMEM */
> >  			}
> >  
> > @@ -516,7 +517,7 @@ blk_status_t btrfs_submit_compressed_write(struct btrfs_inode *inode, u64 start,
> >  	BUG_ON(ret); /* -ENOMEM */
> >  
> >  	if (!skip_sum) {
> > -		ret = btrfs_csum_one_bio(inode, bio, start, 1);
> > +		ret = btrfs_csum_one_bio(inode, bio, start, true);
> >  		BUG_ON(ret); /* -ENOMEM */
> >  	}
> >  
> > diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> > index f07c82fafa04..be245b4b8efe 100644
> > --- a/fs/btrfs/ctree.h
> > +++ b/fs/btrfs/ctree.h
> > @@ -3111,7 +3111,7 @@ int btrfs_csum_file_blocks(struct btrfs_trans_handle *trans,
> >  			   struct btrfs_root *root,
> >  			   struct btrfs_ordered_sum *sums);
> >  blk_status_t btrfs_csum_one_bio(struct btrfs_inode *inode, struct bio *bio,
> > -				u64 file_start, int contig);
> > +				u64 offset, bool one_ordered);
> >  int btrfs_lookup_csums_range(struct btrfs_root *root, u64 start, u64 end,
> >  			     struct list_head *list, int search_commit);
> >  void btrfs_extent_item_to_extent_map(struct btrfs_inode *inode,
> > diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
> > index 2673c6ba7a4e..844fae923340 100644
> > --- a/fs/btrfs/file-item.c
> > +++ b/fs/btrfs/file-item.c
> > @@ -614,28 +614,28 @@ int btrfs_lookup_csums_range(struct btrfs_root *root, u64 start, u64 end,
> >   * btrfs_csum_one_bio - Calculates checksums of the data contained inside a bio
> >   * @inode:	 Owner of the data inside the bio
> >   * @bio:	 Contains the data to be checksummed
> > - * @file_start:  offset in file this bio begins to describe
> > - * @contig:	 Boolean. If true/1 means all bio vecs in this bio are
> > - *		 contiguous and they begin at @file_start in the file. False/0
> > - *		 means this bio can contain potentially discontiguous bio vecs
> > - *		 so the logical offset of each should be calculated separately.
> > + * @offset:      If (u64)-1, @bio may contain discontiguous bio vecs, so the
> > + *               file offsets are determined from the page offsets in the bio.
> > + *               Otherwise, this is the starting file offset of the bio vecs in
> > + *               @bio, which must be contiguous.
> > + * @one_ordered: If true, @bio only refers to one ordered extent.
> 
> nit: I don't have strong preference but my gut feeling tells me
> "single_ordered" might be more explicit/informative. But unless someone
> else thinks the same one_ordered would also make do
> 
> >   */
> >  blk_status_t btrfs_csum_one_bio(struct btrfs_inode *inode, struct bio *bio,
> > -		       u64 file_start, int contig)
> > +				u64 offset, bool one_ordered)
> >  {
> >  	struct btrfs_fs_info *fs_info = inode->root->fs_info;
> >  	SHASH_DESC_ON_STACK(shash, fs_info->csum_shash);
> >  	struct btrfs_ordered_sum *sums;
> >  	struct btrfs_ordered_extent *ordered = NULL;
> > +	const bool page_offsets = (offset == (u64)-1);
> 
> nit: Again, instead of page_offsets perhaps use_page_offsets, somewhat
> more explicit/informative.

Sure, that sounds better.

> >  	char *data;
> >  	struct bvec_iter iter;
> >  	struct bio_vec bvec;
> >  	int index;
> > -	int nr_sectors;
> > +	int blockcount;
> >  	unsigned long total_bytes = 0;
> >  	unsigned long this_sum_bytes = 0;
> >  	int i;
> > -	u64 offset;
> >  	unsigned nofs_flag;
> >  
> >  	nofs_flag = memalloc_nofs_save();
> > @@ -649,18 +649,13 @@ blk_status_t btrfs_csum_one_bio(struct btrfs_inode *inode, struct bio *bio,
> >  	sums->len = bio->bi_iter.bi_size;
> >  	INIT_LIST_HEAD(&sums->list);
> >  
> > -	if (contig)
> > -		offset = file_start;
> > -	else
> > -		offset = 0; /* shut up gcc */
> > -
> >  	sums->bytenr = bio->bi_iter.bi_sector << 9;
> >  	index = 0;
> >  
> >  	shash->tfm = fs_info->csum_shash;
> >  
> >  	bio_for_each_segment(bvec, bio, iter) {
> > -		if (!contig)
> > +		if (page_offsets)
> >  			offset = page_offset(bvec.bv_page) + bvec.bv_offset;
> >  
> >  		if (!ordered) {
> > @@ -668,13 +663,14 @@ blk_status_t btrfs_csum_one_bio(struct btrfs_inode *inode, struct bio *bio,
> >  			BUG_ON(!ordered); /* Logic error */
> >  		}
> >  
> > -		nr_sectors = BTRFS_BYTES_TO_BLKS(fs_info,
> > +		blockcount = BTRFS_BYTES_TO_BLKS(fs_info,
> >  						 bvec.bv_len + fs_info->sectorsize
> >  						 - 1);
> >  
> > -		for (i = 0; i < nr_sectors; i++) {
> > -			if (offset >= ordered->file_offset + ordered->num_bytes ||
> > -			    offset < ordered->file_offset) {
> > +		for (i = 0; i < blockcount; i++) {
> > +			if (!one_ordered &&
> > +			    (offset >= ordered->file_offset + ordered->num_bytes ||
> > +			     offset < ordered->file_offset)) {
> 
> Since you are changing this hunk, how about using the in_range macro:
> 
> if (!one_ordered && !in_range(offset, ordered->file_offset,
> ordered->num_bytes) { foo

Will do (although I don't like that that macro evaluates b and first
twice. Someone changing the code later might not notice that.)

> Though I think the "change the ordered extent now that we are working on
> a different range" code should be factored out in a separate function
> because currently it's somewhat breaking the flow of reading.
> 
> >  				unsigned long bytes_left;
> >  
> >  				sums->len = this_sum_bytes;
> > @@ -705,7 +701,8 @@ blk_status_t btrfs_csum_one_bio(struct btrfs_inode *inode, struct bio *bio,
> >  					    sums->sums + index);
> >  			kunmap_atomic(data);
> >  			index += fs_info->csum_size;
> > -			offset += fs_info->sectorsize;
> > +			if (!one_ordered)
> > +				offset += fs_info->sectorsize;
> 
> Instead of adding one additional conditional op can't offset always be
> incremented but in the case of one_ordered then the !in_range check
> should always be false i.e we won't be using the offset to lookup a new OE?

I did it conditionally so that it's clearer that the offset isn't needed
for the one_ordered case, but I can drop the check.

> >  			this_sum_bytes += fs_info->sectorsize;
> >  			total_bytes += fs_info->sectorsize;
> >  		}
> 
> 
> <snip>

  reply	other threads:[~2021-08-20 17:37 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-17 21:06 [PATCH v10 00/14] btrfs: add ioctls and send/receive support for reading/writing compressed data Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 01/14] fs: export rw_verify_area() Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 02/14] fs: export variant of generic_write_checks without iov_iter Omar Sandoval
2021-08-20  7:59   ` Nikolay Borisov
2021-08-20 17:31     ` Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 03/14] btrfs: don't advance offset for compressed bios in btrfs_csum_one_bio() Omar Sandoval
2021-08-20  8:08   ` Nikolay Borisov
2021-08-20 17:37     ` Omar Sandoval [this message]
2021-08-17 21:06 ` [PATCH v10 04/14] btrfs: add ram_bytes and offset to btrfs_ordered_extent Omar Sandoval
2021-08-20  8:34   ` Nikolay Borisov
2021-08-20 17:43     ` Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 05/14] btrfs: support different disk extent size for delalloc Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 06/14] btrfs: optionally extend i_size in cow_file_range_inline() Omar Sandoval
2021-08-20  8:51   ` Nikolay Borisov
2021-08-20  9:13     ` Qu Wenruo
2021-08-20 18:11       ` Omar Sandoval
2021-08-21  1:11         ` Qu Wenruo
2021-08-23 18:16           ` Omar Sandoval
2021-08-23 23:32             ` Qu Wenruo
2021-08-23 23:46               ` Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 07/14] btrfs: add definitions + documentation for encoded I/O ioctls Omar Sandoval
2021-08-20  8:56   ` Nikolay Borisov
2021-08-20 17:48     ` Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 08/14] btrfs: add BTRFS_IOC_ENCODED_READ Omar Sandoval
2021-08-20 12:30   ` Nikolay Borisov
2021-08-20 17:58     ` Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 09/14] btrfs: add BTRFS_IOC_ENCODED_WRITE Omar Sandoval
2021-08-20 13:44   ` Nikolay Borisov
2021-08-20 17:59     ` Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 10/14] btrfs: add send stream v2 definitions Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 11/14] btrfs: send: write larger chunks when using stream v2 Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 12/14] btrfs: send: allocate send buffer with alloc_page() and vmap() for v2 Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 13/14] btrfs: send: send compressed extents with encoded writes Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 14/14] btrfs: send: enable support for stream v2 and compressed writes Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 01/10] btrfs-progs: receive: support v2 send stream larger tlv_len Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 02/10] btrfs-progs: receive: dynamically allocate sctx->read_buf Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 03/10] btrfs-progs: receive: support v2 send stream DATA tlv format Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 04/10] btrfs-progs: receive: add send stream v2 cmds and attrs to send.h Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 05/10] btrfs-progs: receive: process encoded_write commands Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 06/10] btrfs-progs: receive: encoded_write fallback to explicit decode and write Omar Sandoval
2021-08-18 18:07   ` Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 07/10] btrfs-progs: receive: process fallocate commands Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 08/10] btrfs-progs: receive: process setflags ioctl commands Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 09/10] btrfs-progs: send: stream v2 ioctl flags Omar Sandoval
2021-08-17 21:06 ` [PATCH v10 10/10] btrfs-progs: receive: add tests for basic encoded_write send/receive Omar Sandoval

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=YR/oT2dXaU3pTJE+@relinquished.localdomain \
    --to=osandov@osandov.com \
    --cc=kernel-team@fb.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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