public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Schwab <schwab@linux-m68k.org>
To: Qu Wenruo <wqu@suse.com>
Cc: u-boot@lists.denx.de, linux-btrfs@vger.kernel.org,
	Sam Winchenbach <swichenbach@tethers.com>
Subject: Re: [PATCH] fs/btrfs: handle data extents, which crosss stripe boundaries, correctly
Date: Sun, 12 Feb 2023 16:37:32 +0100	[thread overview]
Message-ID: <87ttzqsxmr.fsf@igel.home> (raw)
In-Reply-To: <57ad584676de5b72ae422a22dc36922285405291.1672362424.git.wqu@suse.com> (Qu Wenruo's message of "Fri, 30 Dec 2022 09:07:05 +0800")

On Dez 30 2022, Qu Wenruo wrote:

> [BUG]
> Since btrfs supports single device RAID0 at mkfs time after btrfs-progs
> v5.14, if we create a single device raid0 btrfs, and created a file
> crossing stripe boundary:
>
>   # mkfs.btrfs -m dup -d raid0 test.img
>   # mount test.img mnt
>   # xfs_io -f -c "pwrite 0 128K" mnt/file
>   # umount mnt
>
> Since btrfs is using 64K as stripe length, above 128K data write is
> definitely going to cross at least one stripe boundary.
>
> Then u-boot would fail to read above 128K file:
>
>  => host bind 0 /home/adam/test.img
>  => ls host 0
>  <   >     131072  Fri Dec 30 00:18:25 2022  file
>  => load host 0 0 file
>  BTRFS: An error occurred while reading file file
>  Failed to load 'file'
>
> [CAUSE]
> Unlike tree blocks read, data extent reads doesn't consider cases in which
> one data extent can cross stripe boundary.
>
> In read_data_extent(), we just call btrfs_map_block() once and read the
> first mapped range.
>
> And if the first mapped range is smaller than the desired range, it
> would return error.
>
> But since even single device btrfs can utilize RAID0 profiles, the first
> mapped range can only be at most 64K for RAID0 profiles, and cause false
> error.
>
> [FIX]
> Just like read_whole_eb(), we should call btrfs_map_block() in a loop
> until we read all data.
>
> Since we're here, also add extra error messages for the following cases:
>
> - btrfs_map_block() failure
>   We already have the error message for it.
>
> - Missing device
>   This should not happen, as we only support single device for now.
>
> - __btrfs_devread() failure
>
> With this bug fixed, btrfs driver of u-boot can properly read the above
> 128K file, and have the correct content:
>
>  => host bind 0 /home/adam/test.img
>  => ls host 0
>  <   >     131072  Fri Dec 30 00:18:25 2022  file
>  => load host 0 0 file
>  131072 bytes read in 0 ms
>  => md5sum 0 0x20000
>  md5 for 00000000 ... 0001ffff ==> d48858312a922db7eb86377f638dbc9f
>  ^^^ Above md5sum also matches.
>
> Reported-by: Sam Winchenbach <swichenbach@tethers.com>
> Signed-off-by: Qu Wenruo <wqu@suse.com>

This breaks btrfs on the HiFive Unmatched.

=> pci enum
PCIE-0: Link up (Gen1-x8, Bus0)
=> nvme scan
=> load nvme 0:2 0x8c000000 /boot/dtb/sifive/hifive-unmatched-a00.dtb
[hangs]

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

  parent reply	other threads:[~2023-02-12 15:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30  1:07 [PATCH] fs/btrfs: handle data extents, which crosss stripe boundaries, correctly Qu Wenruo
2023-01-12 15:19 ` Tom Rini
2023-02-12 15:37 ` Andreas Schwab [this message]
2023-02-12 16:01   ` Andreas Schwab
2023-02-12 16:20     ` Andreas Schwab
2023-02-13  0:19       ` Qu Wenruo
2023-02-13 18:25         ` Andreas Schwab

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=87ttzqsxmr.fsf@igel.home \
    --to=schwab@linux-m68k.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=swichenbach@tethers.com \
    --cc=u-boot@lists.denx.de \
    --cc=wqu@suse.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