linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Zhao Lei <zhaolei@cn.fujitsu.com>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 1/3] btrfs: Continue write in case of can_not_nocow
Date: Fri, 26 Feb 2016 10:41:31 +0500	[thread overview]
Message-ID: <20160226104131.21d98d57@natsu> (raw)
In-Reply-To: <9b89157957abcc87a6ea0530989a4984794484cd.1452078012.git.zhaolei@cn.fujitsu.com>

[-- Attachment #1: Type: text/plain, Size: 2957 bytes --]

On Wed, 6 Jan 2016 19:00:17 +0800
Zhao Lei <zhaolei@cn.fujitsu.com> wrote:

> btrfs failed in xfstests btrfs/080 with -o nodatacow.
> 
> Can be reproduced by following script:
>   DEV=/dev/vdg
>   MNT=/mnt/tmp
> 
>   umount $DEV &>/dev/null
>   mkfs.btrfs -f $DEV
>   mount -o nodatacow $DEV $MNT
> 
>   dd if=/dev/zero of=$MNT/test bs=1 count=2048 &
>   btrfs subvolume snapshot -r $MNT $MNT/test_snap &
>   wait
>   --
>   We can see dd failed on NO_SPACE.
> 
> Reason:
>   __btrfs_buffered_write should run cow write when no_cow impossible,
>   and current code is designed with above logic.
>   But check_can_nocow() have 2 type of return value(0 and <0) on
>   can_not_no_cow, and current code only continue write on first case,
>   the second case happened in doing subvolume.
> 
> Fix:
>   Continue write when check_can_nocow() return 0 and <0.
> 
> Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>

Guys please don't forget about this patch. It solves real problem for people,
http://www.spinics.net/lists/linux-btrfs/msg51276.html
http://www.spinics.net/lists/linux-btrfs/msg51819.html
but it's not in 4.4.1, not in 4.4.2... and now not in 4.4.3

> ---
>  fs/btrfs/file.c | 37 +++++++++++++++++--------------------
>  1 file changed, 17 insertions(+), 20 deletions(-)
> 
> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> index 977e715..11fd981 100644
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -1516,27 +1516,24 @@ static noinline ssize_t __btrfs_buffered_write(struct file *file,
>  
>  		reserve_bytes = num_pages << PAGE_CACHE_SHIFT;
>  
> -		if (BTRFS_I(inode)->flags & (BTRFS_INODE_NODATACOW |
> -					     BTRFS_INODE_PREALLOC)) {
> -			ret = check_can_nocow(inode, pos, &write_bytes);
> -			if (ret < 0)
> -				break;
> -			if (ret > 0) {
> -				/*
> -				 * For nodata cow case, no need to reserve
> -				 * data space.
> -				 */
> -				only_release_metadata = true;
> -				/*
> -				 * our prealloc extent may be smaller than
> -				 * write_bytes, so scale down.
> -				 */
> -				num_pages = DIV_ROUND_UP(write_bytes + offset,
> -							 PAGE_CACHE_SIZE);
> -				reserve_bytes = num_pages << PAGE_CACHE_SHIFT;
> -				goto reserve_metadata;
> -			}
> +		if ((BTRFS_I(inode)->flags & (BTRFS_INODE_NODATACOW |
> +					      BTRFS_INODE_PREALLOC)) &&
> +		    check_can_nocow(inode, pos, &write_bytes) > 0) {
> +			/*
> +			 * For nodata cow case, no need to reserve
> +			 * data space.
> +			 */
> +			only_release_metadata = true;
> +			/*
> +			 * our prealloc extent may be smaller than
> +			 * write_bytes, so scale down.
> +			 */
> +			num_pages = DIV_ROUND_UP(write_bytes + offset,
> +						 PAGE_CACHE_SIZE);
> +			reserve_bytes = num_pages << PAGE_CACHE_SHIFT;
> +			goto reserve_metadata;
>  		}
> +
>  		ret = btrfs_check_data_free_space(inode, pos, write_bytes);
>  		if (ret < 0)
>  			break;


-- 
With respect,
Roman

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  parent reply	other threads:[~2016-02-26  5:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-06 11:00 [PATCH 1/3] btrfs: Continue write in case of can_not_nocow Zhao Lei
2016-01-06 11:00 ` [PATCH 2/3] btrfs: delete no_used argument in btrfs_copy_from_user Zhao Lei
2016-01-06 11:00 ` [PATCH 3/3] btrfs: merge functions for wait snapshot creation Zhao Lei
2016-01-20 20:48 ` [PATCH 1/3] btrfs: Continue write in case of can_not_nocow Filipe Manana
2016-01-21  3:39   ` Zhao Lei
2016-02-26  5:41 ` Roman Mamedov [this message]
2016-02-26 14:57   ` Chris Mason

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=20160226104131.21d98d57@natsu \
    --to=rm@romanrm.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=zhaolei@cn.fujitsu.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).