From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Eliza May <eliza@riseup.net>, linux-btrfs@vger.kernel.org
Subject: Re: Help with ROFS on Cache Folder Deletion
Date: Mon, 6 May 2024 07:56:22 +0930 [thread overview]
Message-ID: <0fe390c1-c6da-491a-88c2-9d419d2486c0@gmx.com> (raw)
In-Reply-To: <7b7cf8e4-90ff-438d-817a-445ce13f5767@riseup.net>
在 2024/5/6 06:02, Eliza May 写道:
> Hi all,
>
> I have run the tests, removed the failing ram, and the results are here:
>
> https://termbin.com/rrsn
>
> Is this recoverable with a repair?
Yes.
That bitflip introduced backref item is the only corruption, thus "btrfs
check --repair" should be able to handle it.
Thanks,
Qu
>
> (My other filesystem returned no errors, and is not included in this.)
>
> Thank you,
>
> Eliza
>
>
> On 5/2/24 12:17 AM, Qu Wenruo wrote:
>>
>>
>> 在 2024/5/2 15:59, Eliza May 写道:
>>> Hi,
>>>
>>>
>>> I am trying to remove the paru .cache folder from my computer, but every
>>> time I do my btrfs filesystem goes read-only. Here is the dmesg output:
>>> https://termbin.com/f4sw
>>>
>>> A scrub found no errors, and I have not yet ran a check -- I will be
>>> doing so and reporting back when I figure out how to do so.
>>>
>>>
>>> My filesystem is a main partition, a separate home subvolume, a var/log
>>> subvolume, and a /var/cache/pacman/pkg subfolder, but I am attempting to
>>> delete the paru one; not the pacman one.
>>>
>>>
>>> If there are any other logs or details I should include, let me know.
>>
>> The dump tree shows:
>>
>> [ 1623.783513] item 97 key (3069062266880 169 0) itemoff 13049
>> itemsize 33
>> [ 1623.783514] extent refs 1 gen 1396868 flags 2
>> [ 1623.783515] ref#0: tree block backref root 16391
>> ...
>> [ 1623.783683] BTRFS critical (device nvme0n1p2: state EA): unable to
>> find ref byte nr 3069062266880 parent 0 root 7 owner 0 offset 0 slot 98
>>
>> This means the bytenr 3069062266880 should have a tree backref for
>> root 7.
>> But the dump tree shows it belongs to root 16391.
>>
>> Furthermore this looks like a memory biflip:
>>
>> hex(7) = 0x0007
>> hex(16391) = 0x4007
>>
>> So please unmount all your fs and run a memtest first to make sure your
>> hardware memory is working correctly.
>> And do necessary memory replacement (if possible).
>>
>> Then finally run "btrfs check --readonly" for the unmounted fs, to make
>> sure that is the only error (please paste the output).
>>
>> Then we can determine if it's safe to run "btrfs check --repair" or
>> there are too many corruption and can only do a data salvage.
>> (I bet a repair can be done, but still want to be sure)
>>
>> Thanks,
>> Qu
>>>
>>>
>>> Thank you,
>>>
>>> Eliza
>>>
>>>
prev parent reply other threads:[~2024-05-05 22:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 6:29 Help with ROFS on Cache Folder Deletion Eliza May
2024-05-02 7:17 ` Qu Wenruo
2024-05-05 20:32 ` Eliza May
2024-05-05 22:26 ` Qu Wenruo [this message]
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=0fe390c1-c6da-491a-88c2-9d419d2486c0@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=eliza@riseup.net \
--cc=linux-btrfs@vger.kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).