From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B7176C4332F for ; Thu, 29 Dec 2022 00:23:20 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8E7368545E; Thu, 29 Dec 2022 01:23:18 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=tethers.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=tethers.com header.i=@tethers.com header.b="Z8DZp5Qy"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1FA9385399; Wed, 28 Dec 2022 21:51:46 +0100 (CET) Received: from mail.tethers.com (mail.tethers.com [50.205.100.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 3E133851E6 for ; Wed, 28 Dec 2022 21:51:40 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=tethers.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=swichenbach@tethers.com DKIM-Signature: v=1; a=rsa-sha256; d=tethers.com; s=s2; c=simple/simple; t=1672260697; h=from:subject:to:date:message-id; bh=IlcyE30a45i99m8cXu4Mc0ayJEQO7E921w4fvH9LasQ=; b=Z8DZp5Qyb+COKw8ZCUPKKECWhs39uuMduzXENaIzJRE9SyDQBetwohoEWSRQuPDEzX0+IjNVRbZ hXAG+cibn6c3k+BgMkDuvNyI7VV/KPhkbVhEDSiy4CqNb1vtZ6GfgbvaaKT6FSPKsPbt7FgjGw7ol eYBHmlFFyyh5dPuSUndO9P+YsqjOpSqg1aGxNg+e2adJdizG/vJyBaAd8wrQm5Oa2hTHdRO9Gdc2+ tecbbmQhEVZyZGYi4FdwzpAXyuvJf+3X5WtTL8q3jQfho4Sah6VSvjeY61D0u05iTGBUfBN/74HNO ZH3EVgGWYbaG2nMiFWCZI8+CHwN4VunYYXug== Received: from Exchange2019.secure.tethers.com (172.23.48.153) by exchange2019.secure.tethers.com (172.23.48.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.1118.20; Wed, 28 Dec 2022 12:51:37 -0800 Received: from Exchange2019.secure.tethers.com ([fe80::ffb3:a1ad:8f70:8ff3]) by EXCHANGE2019.secure.tethers.com ([fe80::ffb3:a1ad:8f70:8ff3%14]) with mapi id 15.02.1118.020; Wed, 28 Dec 2022 12:51:37 -0800 From: Sam Winchenbach To: "u-boot@lists.denx.de" Subject: Possible bug in BTRFS w/ Duplication Thread-Topic: Possible bug in BTRFS w/ Duplication Thread-Index: Adka+vuz/Z7NK3MJQMCy/azwMbd3OA== Date: Wed, 28 Dec 2022 20:51:37 +0000 Message-ID: <62218a2a5a274ada96f97f7ac4e151ef@tethers.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.56.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 29 Dec 2022 01:23:16 +0100 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean 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 le= ngth 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 brea= k this check here: read =3D len; num_copies =3D btrfs_num_copies(fs_info, logical, len); for (i =3D 1; i <=3D num_copies; i++) { ret =3D read_extent_data(fs_info, dest, logical, &read, i); if (ret < 0 || read !=3D len) { continue; } finished =3D true; break; } The problem being that read is always less than len. =20 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 p= ointers on how this code is supposed to work would be greatly appreciated. Thanks. =3D=3D=3D EXAMPLE 2 =3D=3D=3D Zynq> load mmc 1:0 0 16K [btrfs_file_read,fs/btrfs/inode.c:710] =3D=3D=3D read the aligned part =3D= =3D=3D [btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data (ret = =3D 0, read =3D 16384, len =3D 16384) [read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block (len =3D= 16384) [read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len =3D = 28672) [read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len =3D 1= 6384) [read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len =3D 16= 384) [btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data (ret = =3D 0, read =3D 16384, len =3D 16384) cur: 0, extent_num_bytes: 16384, aligned_end: 16384 16384 bytes read in 100 ms (159.2 KiB/s) =3D=3D=3D EXAMPLE 2 =3D=3D=3D Zynq> load mmc 1:0 0 32K [btrfs_file_read,fs/btrfs/inode.c:710] =3D=3D=3D read the aligned part =3D= =3D=3D [btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data (ret = =3D 0, read =3D 32768, len =3D 32768) [read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block (len =3D= 32768) [read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len =3D = 12288) [read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len =3D 1= 2288) [read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len =3D 12= 288) [btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data (ret = =3D 0, read =3D 12288, len =3D 32768) [btrfs_read_extent_reg,fs/btrfs/inode.c:458] before read_extent_data (ret = =3D 0, read =3D 12288, len =3D 32768) [read_extent_data,fs/btrfs/disk-io.c:547] before __btrfs_map_block (len =3D= 12288) [read_extent_data,fs/btrfs/disk-io.c:550] after __btrfs_map_block (len =3D = 12288) [read_extent_data,fs/btrfs/disk-io.c:565] before __btrfs_devread (len =3D 1= 2288) [read_extent_data,fs/btrfs/disk-io.c:568] after __btrfs_devread (len =3D 12= 288) [btrfs_read_extent_reg,fs/btrfs/inode.c:460] after read_extent_data (ret = =3D 0, read =3D 12288, len =3D 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=20 Tethers Unlimited, Inc. | Connect Your Universe | www.tethers.com=20 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 o= f the individual or entity named above. If the reader of this message is no= t the intended recipient, you are hereby notified that any dissemination, d= istribution 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 i= t. Thank you. ITAR/EAR NOTICE: This email and/or attachments may contain technical data c= ontrolled by the US International Traffic and Arms Regulations (ITAR) or th= e 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 leg= ally shared with another party.