From: Sam Winchenbach <swichenbach@tethers.com>
To: "u-boot@lists.denx.de" <u-boot@lists.denx.de>
Subject: Possible bug in BTRFS w/ Duplication
Date: Wed, 28 Dec 2022 20:51:37 +0000 [thread overview]
Message-ID: <62218a2a5a274ada96f97f7ac4e151ef@tethers.com> (raw)
Hello,
Hello, I have hit the following situation when trying to load files from a BTRFS partition with duplication enabled.
In the first example I read a 16KiB file - __btrfs_map_block() changes the length to something larger than the file being read. This works fine, as length is later clamped to the file size.
In the second example, __btrfs_map_block() changes the length parameter to something smaller than the file (the size of a stripe). This seems to break this check here:
read = len;
num_copies = btrfs_num_copies(fs_info, logical, len);
for (i = 1; i <= num_copies; i++) {
ret = read_extent_data(fs_info, dest, logical, &read, i);
if (ret < 0 || read != len) {
continue;
}
finished = true;
break;
}
The problem being that read is always less than len.
I am not sure if __btrfs_map_block is changing "len" to the incorrect value, or if there is some logic in "read_extent_data" that isn't correct. Any pointers on how this code is supposed to work would be greatly appreciated.
Thanks.
=== EXAMPLE 2 ===
Zynq> load mmc 1:0 0 16K
[btrfs_file_read,fs/btrfs/inode.c:710] === read the aligned part ===
[btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data (ret = 0, read = 16384, len = 16384)
[read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block (len = 16384)
[read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len = 28672)
[read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len = 16384)
[read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len = 16384)
[btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data (ret = 0, read = 16384, len = 16384)
cur: 0, extent_num_bytes: 16384, aligned_end: 16384
16384 bytes read in 100 ms (159.2 KiB/s)
=== EXAMPLE 2 ===
Zynq> load mmc 1:0 0 32K
[btrfs_file_read,fs/btrfs/inode.c:710] === read the aligned part ===
[btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data (ret = 0, read = 32768, len = 32768)
[read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block (len = 32768)
[read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len = 12288)
[btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data (ret = 0, read = 12288, len = 32768)
[btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data (ret = 0, read = 12288, len = 32768)
[read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block (len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len = 12288)
[read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len = 12288)
[btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data (ret = 0, read = 12288, len = 32768)
file: fs/btrfs/inode.c, line: 468
cur: 0, extent_num_bytes: 32768, aligned_end: 32768
-----> btrfs_read_extent_reg: -5, line: 758
BTRFS: An error occurred while reading file 32K
Failed to load '32K'
Sam Winchenbach
Embedded Software Engineer III
Tethers Unlimited, Inc. | Connect Your Universe | www.tethers.com
swinchenbach@tethers.com | C: 207-974-6934
11711 North Creek Pkwy # D113, Bothell, WA 98011-8808, USA
CONFIDENTIALITY NOTE: The information contained in this transmission may be privileged and confidential information and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender that you have received this communication in error and then delete it. Thank you.
ITAR/EAR NOTICE: This email and/or attachments may contain technical data controlled by the US International Traffic and Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export from the US or disclosure to foreign nationals in the U.S. without an export license is a violation of law. It is the recipient's responsibility to assure this item can be legally shared with another party.
next reply other threads:[~2022-12-29 0:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-28 20:51 Sam Winchenbach [this message]
2022-12-29 14:12 ` Possible bug in BTRFS w/ Duplication Heinrich Schuchardt
2022-12-30 0:00 ` Qu Wenruo
2022-12-30 15:28 ` Sam Winchenbach
2022-12-31 0:10 ` Qu Wenruo
2023-01-03 13:36 ` Sam Winchenbach
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=62218a2a5a274ada96f97f7ac4e151ef@tethers.com \
--to=swichenbach@tethers.com \
--cc=u-boot@lists.denx.de \
/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