Help with ROFS on Cache Folder Deletion

Help with ROFS on Cache Folder Deletion

[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.


Thank you,

Eliza

Re: Help with ROFS on Cache Folder Deletion

[Qu Wenruo]

在 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
>
>

Re: Help with ROFS on Cache Folder Deletion

[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?

(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
>>
>>

Re: Help with ROFS on Cache Folder Deletion

[Qu Wenruo]

在 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
>>>
>>>