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."
next prev 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