lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 26 Dec 2022 13:15:41 +0500 From: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com> To: Qu Wenruo <quwenruo.btrfs@....com> Cc: wqu@...e.com, dsterba@...e.com, Btrfs BTRFS <linux-btrfs@...r.kernel.org>, Linux List Kernel Mailing <linux-kernel@...r.kernel.org> Subject: Re: [6.2][regression] after commit 947a629988f191807d2d22ba63ae18259bb645c5 btrfs volume periodical forced switch to readonly after a lot of disk writes On Mon, Dec 26, 2022 at 8:29 AM Qu Wenruo <quwenruo.btrfs@....com> wrote: > > > OK, indeed a level mismatch. > > From the remaining lines, it shows we're failing at > do_free_extent_accounting(), which failed at the btrfs_del_csums(). > > And inside btrfs_del_csums(), what we do are all regular btree > operations, thus the tree level check should work without problem. > > Thus it seems to be a corrupted csum tree. Do I need to debug anything else to understand the cause of the error? Thanks. > Could you please run "btrfs check --readonly" from a liveCD? > There are tons of possible false alerts if ran on a RW mounted fs. > # btrfs check --readonly /dev/nvme0n1p3 Opening filesystem to check... Checking filesystem on /dev/nvme0n1p3 UUID: 40e0b5d2-df54-46e0-b6f4-2f868296271d [1/7] checking root items [2/7] checking extents [3/7] checking free space tree [4/7] checking fs roots [5/7] checking only csums items (without verifying data) [6/7] checking root refs [7/7] checking quota groups skipped (not enabled on this FS) found 6828416307200 bytes used, no error found total csum bytes: 6651838248 total tree bytes: 16378380288 total fs tree bytes: 7483179008 total extent tree bytes: 1228210176 btree space waste bytes: 2413299694 file data blocks allocated: 6899999100928 referenced 7488299450368 [root@...alhost-live ~]# With liveCD looks like all OK (no errors found). -- Best Regards, Mike Gavrilov.
Powered by blists - more mailing lists