BTRFS: error (device nvme0n1p3 state A) in btrfs_create_new_inode:6670: errno=-17 Object already exists. Nvme, suspension and default_ps_max_latency_us

Ask Fedora
, , ,
1

Disclaimer

These considerations were made with the help of ChatGPT.

Current System

  • Fedora 43

  • Btrfs on / and /home

  • Laptop: Asus ProArt P16

  • Suspend / Hibernation: Disabled

  • Power Button Behavior: Do nothing

I always use the notebook plugged in, and I never close the lid to power it off.

Problem

Today, when I booted the OS, I found that the / and /home subvolumes were mounted in read-only mode.
Checking dmesg, I found:

[   27.927279] BTRFS: error (device nvme0n1p3 state A) in btrfs_create_new_inode:6670: errno=-17 Object already exists
[   27.927283] BTRFS info (device nvme0n1p3 state EA): forced readonly
[   27.951837] systemd-journald[777]: /var/log/journal/5463857fb23d44c4b57b61c5e9ea6fd8/system.journal: Journal file corrupted, rotating.

Resolution

I booted from a live ISO and ran the following commands:

# Verify filesystem
sudo btrfs check --readonly /dev/nvme0n1p3

# Attempt rescue: no errors found
sudo btrfs rescue super-recover /dev/nvme0n1p3
sudo btrfs rescue chunk-recover /dev/nvme0n1p3

# Scrub (no errors found)
sudo mount -o defaults /dev/nvme0n1p3 /mnt/btrfs
sudo btrfs scrub start -Bd /mnt/btrfs

# Repair (correct errors)
sudo btrfs check --repair /dev/nvme0n1p3

Considerations

After restoring the system, I tried to investigate the possible causes. The AI suggested that probable causes for this error are:

  • Power loss / hard reset

  • System freeze

  • I/O problem with NVMe

  • Kernel bug

In my case:

  • The system is always plugged in

  • I never perform a hard reset

  • The system never freezes

  • I upgrade daily with dnf

The remaining suspect is NVMe I/O. The AI pointed me to the kernel parameter:

/sys/module/nvme_core/parameters/default_ps_max_latency_us

This sets the maximum allowed wake-up time (in microseconds) from Autonomous Power State Transitions (APST) power-saving modes. My output was 100000, which corresponds to PS4 being enabled.

Each NVMe device declares a table of power states:

Power State Exit latency
PS0 0 µs
PS1 ~50 µs
PS2 ~500 µs
PS3 ~5000–10000 µs
PS4 ~25000–100000 µs

  • PS0 = Always on

  • …

  • PS4 = All OFF

To check the disk status, I ran:

sudo nvme id-ctrl /dev/nvme0

The PS4 exlat (exit latency) was 35000, below 100000, meaning the kernel can set the disk to PS4 state.

I also checked unsafe shutdowns:

sudo smartctl -a /dev/nvme0n1

Output: Unsafe Shutdowns: 31
Each unsafe shutdown represents an interrupted write.

Based on this information, I hypothesize the error could be generated by the PS4 state:

Timeline of events:

  • T0 – Disk enters PS4 state

  • T1 – Btrfs writes an inode

  • T2 – Kernel sends wake-up command

  • T3 – NVMe has PS4 exit latency

  • T4 – Some NVMe firmware may delay further, or ACPI may cut power

  • T5 – Kernel calls shutdown() (waits only a few ms)

  • T6 – Metadata incomplete → errors

Conclusion

Could anyone confirm if these considerations and resolution are reasonable?

References

Some years ago, I experienced a “similar” problem on Windows 10/11 with SQL Server:
StackExchange post

[EDIT]

Fix

I run this command to set the value from 100000 to 20000 for disable the PS4 and PS5 Power State.

`sudo grubby --update-kernel=ALL --args="nvme_core.default_ps_max_latency_us=20000`

2

The problem happens before this, a complete dmesg is needed.

This is not a good idea before the problem is understood.

OK so it sounds like there’s an nvme drive quirk and the kernel doesn’t know about it yet? I’d mail the nvme mailing list (found in MAINTAINERS file) and provide the complete dmesg with and without the option, and how often the problem happens without that option.

3

Before the check –repair I tried

  • btrfs check It raised some inode errors
  • btrfs rescue x 2 No errors found
  • btrfs scrub No errors found
  • I retried btrfs check and still there are errors.

Sorry, I ran these commands in a live environment, and I did not save the outputs.

I looked on systemctl for a prior error on Btrfs, but I couldn’t find anything useful. Maybe you can suggest some commands to find the cause?

I tried journalctl | grep btrfs

4

The original post has no mention of errors found with btrfs check - We need to see the errors it reported.

There won’t be any messages in journalctl because the file system went read-only and that will prevent kernel messages from making it to persistent media.

Please boot from the live USB again and run btrfs check --readonly

And also do a normal mount of the file system mount /dev/nvme0n1p3 /mntfollowed by dmesg

And put the output from the commands into a file you can share, and link in the reply. Then we can help. The output will be too long to directly paste here so it’s best to share with a link.

5

You are right, the original post did not include the btrfs check errors.

At that time the system was not bootable, and since I had a full backup of all data, I decided to run btrfs check --repair as a last resort.
Before running --repair, btrfs check reported unresolved directory references (9 error lines), all referring to a GitHub-related .png file. This led me to assume that, in the worst case, I would only lose that single image file.

After running --repair, btrfs check still reported a reference count mismatch, which I did not attempt to fix. Despite this, the system now boots and runs correctly.

I understand that this limits what can be diagnosed retroactively. If it is still useful, I can reboot from a live USB and run btrfs check --readonly, perform a normal mount (mount /dev/nvme0n1p3 /mnt), collect the output of dmesg, and share the logs via a link as suggested.

Please let me know if you would like me to proceed with these steps or if there is anything else I should check given the current state of the filesystem.

6

btrfs check should come up without any errors. Errors mean the file system isn’t consistent. Although it’s possible for problems to be isolated to specific parts of the file system and maybe won’t spread - the reason it goes read-only is to prevent the confusion already encountered from spreading via writes to other parts of the file system. So it’s best to figure out what went wrong and make sure it’s not a continuing problem.

It’s true that a solid backup plan makes it safer to use --repair since there’s a fall back position.

If the problem cause can be isolated to the NVMe drive latency or power (sleep) settings, then that should definitely be reported to NVMe folks so they can get a quirk into the kernel for this make/model drive. But it’s also valid to see if there’s a more recent firmware update for the drive. That’s the sort of thing firmware updates tend to fix after a product has shipped.

Another source for Btrfs errors is faulty RAM (bit flips). Each of these will have unique finger prints so it should be possible to narrow down where the problem is coming from.

7

btrfs check reported warnings, not hard errors. These are most likely related to the corrections the tool itself applied during the check. After that, I ran a full scrub, which did not report any errors or checksum mismatches.

Regarding firmware, the BIOS is currently on firmware version 319. I’ve seen that version 320 was released a few months ago, so I’ll update to that as well to rule out issues that may already have been fixed at the firmware level. The laptop itself is about 7 months old.

I’ll also run a thorough RAM test (memtest).

Thanks

8

Scrub only verifies checksums, it doesn’t do a consistency check. Only btrfs check does a consistency check to verify the correctness of the file system. Any errors mean it’s not consistent, there should be no errors. The source of errors needs to be understood in order to prevent them from happening again.

The main logic board firmware is not the firmware I’m referring to. The NVMe drive itself has separate firmware. Sometimes the manufacturer releases firmware updates directly, other times they only release it via the end user product manufacturer.

9

I have performed a full memtest86+ with no errors.

There is no NVMe firmware. I updated the BIOS firmware.

I have run a Btrfs check, and the result is as follows.

AI suggests that this can be related to the repair and/or old snapshots.

Unfortunately, after the update of the default_ps_max_latency_us , errors still raise now are 33.

What tools can I use to understand the problem?

Thanks

liveuser@localhost-live:~$ sudo btrfs check /dev/nvme0n1p3
Opening filesystem to check…
Checking filesystem on /dev/nvme0n1p3
UUID: 5a79da3a-afb6-4b7a-846f-e5be70def2b0
[1/8] checking log skipped (none written)
[2/8] checking root items
[3/8] checking extents
ref mismatch on [108706131968 4096] extent item 14, found 12
data extent[108706131968, 4096] bytenr mimsmatch, extent item bytenr 108706131968 file item bytenr 0
data extent[108706131968, 4096] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[108706131968, 4096] bytenr mimsmatch, extent item bytenr 108706131968 file item bytenr 0
data extent[108706131968, 4096] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [108706131968 4096]
ref mismatch on [108709425152 4096] extent item 11, found 9
data extent[108709425152, 4096] bytenr mimsmatch, extent item bytenr 108709425152 file item bytenr 0
data extent[108709425152, 4096] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[108709425152, 4096] bytenr mimsmatch, extent item bytenr 108709425152 file item bytenr 0
data extent[108709425152, 4096] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [108709425152 4096]
ref mismatch on [108777738240 4096] extent item 14, found 12
data extent[108777738240, 4096] bytenr mimsmatch, extent item bytenr 108777738240 file item bytenr 0
data extent[108777738240, 4096] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[108777738240, 4096] bytenr mimsmatch, extent item bytenr 108777738240 file item bytenr 0
data extent[108777738240, 4096] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [108777738240 4096]
ref mismatch on [108886646784 4096] extent item 14, found 12
data extent[108886646784, 4096] bytenr mimsmatch, extent item bytenr 108886646784 file item bytenr 0
data extent[108886646784, 4096] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[108886646784, 4096] bytenr mimsmatch, extent item bytenr 108886646784 file item bytenr 0
data extent[108886646784, 4096] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [108886646784 4096]
ref mismatch on [109075341312 4096] extent item 14, found 12
data extent[109075341312, 4096] bytenr mimsmatch, extent item bytenr 109075341312 file item bytenr 0
data extent[109075341312, 4096] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[109075341312, 4096] bytenr mimsmatch, extent item bytenr 109075341312 file item bytenr 0
data extent[109075341312, 4096] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [109075341312 4096]
ref mismatch on [109164244992 4096] extent item 14, found 12
data extent[109164244992, 4096] bytenr mimsmatch, extent item bytenr 109164244992 file item bytenr 0
data extent[109164244992, 4096] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[109164244992, 4096] bytenr mimsmatch, extent item bytenr 109164244992 file item bytenr 0
data extent[109164244992, 4096] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [109164244992 4096]
ref mismatch on [109401321472 4096] extent item 14, found 12
data extent[109401321472, 4096] bytenr mimsmatch, extent item bytenr 109401321472 file item bytenr 0
data extent[109401321472, 4096] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[109401321472, 4096] bytenr mimsmatch, extent item bytenr 109401321472 file item bytenr 0
data extent[109401321472, 4096] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [109401321472 4096]
ref mismatch on [134378655744 8192] extent item 14, found 12
data extent[134378655744, 8192] bytenr mimsmatch, extent item bytenr 134378655744 file item bytenr 0
data extent[134378655744, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[134378655744, 8192] bytenr mimsmatch, extent item bytenr 134378655744 file item bytenr 0
data extent[134378655744, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [134378655744 8192]
ref mismatch on [134389161984 8192] extent item 14, found 12
data extent[134389161984, 8192] bytenr mimsmatch, extent item bytenr 134389161984 file item bytenr 0
data extent[134389161984, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[134389161984, 8192] bytenr mimsmatch, extent item bytenr 134389161984 file item bytenr 0
data extent[134389161984, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [134389161984 8192]
ref mismatch on [134390292480 8192] extent item 14, found 12
data extent[134390292480, 8192] bytenr mimsmatch, extent item bytenr 134390292480 file item bytenr 0
data extent[134390292480, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[134390292480, 8192] bytenr mimsmatch, extent item bytenr 134390292480 file item bytenr 0
data extent[134390292480, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [134390292480 8192]
ref mismatch on [134391074816 8192] extent item 14, found 12
data extent[134391074816, 8192] bytenr mimsmatch, extent item bytenr 134391074816 file item bytenr 0
data extent[134391074816, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[134391074816, 8192] bytenr mimsmatch, extent item bytenr 134391074816 file item bytenr 0
data extent[134391074816, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [134391074816 8192]
ref mismatch on [134397329408 8192] extent item 14, found 12
data extent[134397329408, 8192] bytenr mimsmatch, extent item bytenr 134397329408 file item bytenr 0
data extent[134397329408, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[134397329408, 8192] bytenr mimsmatch, extent item bytenr 134397329408 file item bytenr 0
data extent[134397329408, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [134397329408 8192]
ref mismatch on [134404030464 8192] extent item 14, found 12
data extent[134404030464, 8192] bytenr mimsmatch, extent item bytenr 134404030464 file item bytenr 0
data extent[134404030464, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[134404030464, 8192] bytenr mimsmatch, extent item bytenr 134404030464 file item bytenr 0
data extent[134404030464, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [134404030464 8192]
ref mismatch on [134516363264 12288] extent item 14, found 12
data extent[134516363264, 12288] bytenr mimsmatch, extent item bytenr 134516363264 file item bytenr 0
data extent[134516363264, 12288] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[134516363264, 12288] bytenr mimsmatch, extent item bytenr 134516363264 file item bytenr 0
data extent[134516363264, 12288] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [134516363264 12288]
ref mismatch on [134960566272 8192] extent item 14, found 12
data extent[134960566272, 8192] bytenr mimsmatch, extent item bytenr 134960566272 file item bytenr 0
data extent[134960566272, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[134960566272, 8192] bytenr mimsmatch, extent item bytenr 134960566272 file item bytenr 0
data extent[134960566272, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [134960566272 8192]
ref mismatch on [134962233344 8192] extent item 14, found 12
data extent[134962233344, 8192] bytenr mimsmatch, extent item bytenr 134962233344 file item bytenr 0
data extent[134962233344, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[134962233344, 8192] bytenr mimsmatch, extent item bytenr 134962233344 file item bytenr 0
data extent[134962233344, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [134962233344 8192]
ref mismatch on [134962601984 8192] extent item 14, found 12
data extent[134962601984, 8192] bytenr mimsmatch, extent item bytenr 134962601984 file item bytenr 0
data extent[134962601984, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[134962601984, 8192] bytenr mimsmatch, extent item bytenr 134962601984 file item bytenr 0
data extent[134962601984, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [134962601984 8192]
ref mismatch on [135127560192 8192] extent item 14, found 12
data extent[135127560192, 8192] bytenr mimsmatch, extent item bytenr 135127560192 file item bytenr 0
data extent[135127560192, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[135127560192, 8192] bytenr mimsmatch, extent item bytenr 135127560192 file item bytenr 0
data extent[135127560192, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [135127560192 8192]
ref mismatch on [135146340352 8192] extent item 14, found 12
data extent[135146340352, 8192] bytenr mimsmatch, extent item bytenr 135146340352 file item bytenr 0
data extent[135146340352, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[135146340352, 8192] bytenr mimsmatch, extent item bytenr 135146340352 file item bytenr 0
data extent[135146340352, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [135146340352 8192]
ref mismatch on [135196753920 8192] extent item 14, found 12
data extent[135196753920, 8192] bytenr mimsmatch, extent item bytenr 135196753920 file item bytenr 0
data extent[135196753920, 8192] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[135196753920, 8192] bytenr mimsmatch, extent item bytenr 135196753920 file item bytenr 0
data extent[135196753920, 8192] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [135196753920 8192]
ref mismatch on [135997460480 12288] extent item 14, found 12
data extent[135997460480, 12288] bytenr mimsmatch, extent item bytenr 135997460480 file item bytenr 0
data extent[135997460480, 12288] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[135997460480, 12288] bytenr mimsmatch, extent item bytenr 135997460480 file item bytenr 0
data extent[135997460480, 12288] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [135997460480 12288]
ref mismatch on [135998251008 12288] extent item 14, found 12
data extent[135998251008, 12288] bytenr mimsmatch, extent item bytenr 135998251008 file item bytenr 0
data extent[135998251008, 12288] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[135998251008, 12288] bytenr mimsmatch, extent item bytenr 135998251008 file item bytenr 0
data extent[135998251008, 12288] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [135998251008 12288]
ref mismatch on [135998578688 12288] extent item 14, found 12
data extent[135998578688, 12288] bytenr mimsmatch, extent item bytenr 135998578688 file item bytenr 0
data extent[135998578688, 12288] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[135998578688, 12288] bytenr mimsmatch, extent item bytenr 135998578688 file item bytenr 0
data extent[135998578688, 12288] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [135998578688 12288]
ref mismatch on [136127258624 12288] extent item 14, found 12
data extent[136127258624, 12288] bytenr mimsmatch, extent item bytenr 136127258624 file item bytenr 0
data extent[136127258624, 12288] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[136127258624, 12288] bytenr mimsmatch, extent item bytenr 136127258624 file item bytenr 0
data extent[136127258624, 12288] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [136127258624 12288]
ref mismatch on [136129404928 16384] extent item 14, found 12
data extent[136129404928, 16384] bytenr mimsmatch, extent item bytenr 136129404928 file item bytenr 0
data extent[136129404928, 16384] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[136129404928, 16384] bytenr mimsmatch, extent item bytenr 136129404928 file item bytenr 0
data extent[136129404928, 16384] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [136129404928 16384]
ref mismatch on [136129548288 20480] extent item 11, found 9
data extent[136129548288, 20480] bytenr mimsmatch, extent item bytenr 136129548288 file item bytenr 0
data extent[136129548288, 20480] referencer count mismatch (parent 172671614976) wanted 1 have 0
data extent[136129548288, 20480] bytenr mimsmatch, extent item bytenr 136129548288 file item bytenr 0
data extent[136129548288, 20480] referencer count mismatch (parent 219602649088) wanted 1 have 0
backpointer mismatch on [136129548288 20480]
ref mismatch on [136130199552 16384] extent item 14, found 12
data extent[136130199552, 16384] bytenr mimsmatch, extent item bytenr 136130199552 file item bytenr 0
data extent[136130199552, 16384] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[136130199552, 16384] bytenr mimsmatch, extent item bytenr 136130199552 file item bytenr 0
data extent[136130199552, 16384] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [136130199552 16384]
ref mismatch on [136145211392 16384] extent item 14, found 12
data extent[136145211392, 16384] bytenr mimsmatch, extent item bytenr 136145211392 file item bytenr 0
data extent[136145211392, 16384] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[136145211392, 16384] bytenr mimsmatch, extent item bytenr 136145211392 file item bytenr 0
data extent[136145211392, 16384] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [136145211392 16384]
ref mismatch on [136155037696 20480] extent item 14, found 12
data extent[136155037696, 20480] bytenr mimsmatch, extent item bytenr 136155037696 file item bytenr 0
data extent[136155037696, 20480] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[136155037696, 20480] bytenr mimsmatch, extent item bytenr 136155037696 file item bytenr 0
data extent[136155037696, 20480] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [136155037696 20480]
ref mismatch on [136281296896 12288] extent item 11, found 9
data extent[136281296896, 12288] bytenr mimsmatch, extent item bytenr 136281296896 file item bytenr 0
data extent[136281296896, 12288] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[136281296896, 12288] bytenr mimsmatch, extent item bytenr 136281296896 file item bytenr 0
data extent[136281296896, 12288] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [136281296896 12288]
ref mismatch on [145211674624 24576] extent item 14, found 12
data extent[145211674624, 24576] bytenr mimsmatch, extent item bytenr 145211674624 file item bytenr 0
data extent[145211674624, 24576] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[145211674624, 24576] bytenr mimsmatch, extent item bytenr 145211674624 file item bytenr 0
data extent[145211674624, 24576] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [145211674624 24576]
ref mismatch on [149326233600 53248] extent item 14, found 12
data extent[149326233600, 53248] bytenr mimsmatch, extent item bytenr 149326233600 file item bytenr 0
data extent[149326233600, 53248] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[149326233600, 53248] bytenr mimsmatch, extent item bytenr 149326233600 file item bytenr 0
data extent[149326233600, 53248] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [149326233600 53248]
ref mismatch on [149571932160 49152] extent item 14, found 12
data extent[149571932160, 49152] bytenr mimsmatch, extent item bytenr 149571932160 file item bytenr 0
data extent[149571932160, 49152] referencer count mismatch (parent 219602649088) wanted 1 have 0
data extent[149571932160, 49152] bytenr mimsmatch, extent item bytenr 149571932160 file item bytenr 0
data extent[149571932160, 49152] referencer count mismatch (parent 172671614976) wanted 1 have 0
backpointer mismatch on [149571932160 49152]
ERROR: errors found in extent allocation tree or chunk allocation
[4/8] checking free space tree
[5/8] checking fs roots
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
found 326294581248 bytes used, error(s) found
total csum bytes: 294034880
total tree bytes: 8848949248
total fs tree bytes: 8187265024
total extent tree bytes: 327122944
btree space waste bytes: 1882580070
file data blocks allocated: 2168958410752
referenced 1094921699328

10

Unfortunately we really need dmesg. That is not easy when the file system goes read-only and the kernel messages aren’t saved to stable media. But it does mean the dmesg needs to be retained right away whenever there are issues because these messages are clues and once rebooted they are lost - and we don’t know what happened at the time.

The btrfs check shows extensive extent tree problems. I’m not sure they can be fixed. It might be possible to rebuild, but that often makes things worse. I will ask our upstream developer for an opinion - we’re discussing it on https://matrix.to/#/#btrfs:fedoraproject.org

Since you can still mount it read-only, you should be able to copy out any important files to make sure your backups are up to date before attempting extent tree rebuild.

It’s possible a developer will want to see a btrfs image. This is a copy of the file system metadata only, no data. It’s purely to help make btrfs better, so maybe see what went wrong and why btrfs check is not able to repair the problem.

btrfs-image -t4 -c9 /dev/nvme0n1p3 mybtrfs.image

You can optionally add -ss to mask filenames.

I don’t really have anything to advise right now. But if you need to reformat and reinstall to get back to work, it’s understandable.

11

What kernel version was being used at the time of the problem?

12

To be clear: the system is now fully operational despite the log pasted before.

Now I’m going to reinstall the system and select ext4 (sorry). I think Btrfs it is a good filesystem, but it is too “fragile”.

When an error occurs, there are no tools for understanding and resolving the problem. I appreciate the ro mode to recover the data, but from a user perspective, the lack of tools for diagnose/check/recover is a “no go” choice; the scrubvs check do the situation even worse, scrub: no error, check: pop up some “non-human readable” messages.

Anyway, MANY thanks for the support.

13

The Kernel is

Linux mars 6.18.5-200.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jan 11 17:09:32 UTC 2026 x86_64 GNU/Linux

14

btrfs gives early warning of issues that remain hidden with legacy filesystems, but requires periodic maintenance. I worked in remote sensing using mostly SGI hardware and XFS filesystems. Every data file had a checksum file, and we had to recompute and compare with the saved value before using a file to avoid processing failures that took time to diagnose and repair, resulting in missed release schedules. Btrfs would have been much more efficient.

You will probably not have visible issues with EXT4, but real user experiences with btrfs drive improvements, so using btrfs benefits the Linux community.

There is a very big gap between individual and data centre filesystem use cases. Bcachefs targets individual use cases by trying to minimize data loss on unreliable hardware. By contrast, data centres have both reliable hardware and redundacy. Early detection of bitrot means corrupt data or failed hardware are found before causing problems.

15

I think I expressed myself poorly. What I meant by “fragile” is that, from a laptop / desktop user perspective, Btrfs requires more maintenance and more awareness than most users realistically have.

I fully agree that early detection of corrupted data is a good thing. However, for the average user the practical behavior is different:

  • if a corrupted file is important, they will complain and look for it in their backups;

  • if it is not important, they will usually just delete it and move on.

The problem is that with Btrfs the failure mode is often much harsher. Instead of “this file is broken”, you can end up with the filesystem going read-only, effectively blocking the entire machine, with very limited tools to understand what actually happened.

Personally, I think that before promoting Btrfs widely on desktop systems, there should be user-accessible diagnostic tools. Something like a scan/scrub or consistency check that clearly tells me what is broken and where: the directory, the specific file, and ideally the filename. In my case, I vaguely remember an error mentioning something like github-something.png, and later only generic inode errors in the logs. At that point I had no tools to fix the issue. The only option was searching forums, writing to support, and trying things blindly. And from what I have seen, the most common “solution” people end up with is a full reformat.

I also noticed there is ongoing discussion about Btrfs being the default filesystem. My personal view is that using Btrfs for /home makes sense, but the root filesystem should still be ext4. When the root goes read-only, the system is effectively unusable, and that is a very high price to pay on a personal machine.

The picture changes on critical systems or servers, where you can afford RAID, redundancy, monitoring, and operational procedures. In that context I agree with you. But on desktop and laptop systems, detection alone is not enough: users also need practical, reliable tools to handle problems when they occur.

16

Hello @m4ss1mog , I am an early Butter FS adopter in the Fedora community and I have never looked back. I don’t have ANY issues with my file system on any of the devices running Fedora in my home. BTRFS is quite simply far superior to ext4. So I have to disagree with this statement regarding ease of use.
Have you tried using BTRFS Assistant as a user friendly GUI based tool for Butter FS?

17

Hello @jakfrost,

It’s been almost a year with Fedora and Btrfs without a problem, until a couple of days ago.

And yes, I installed Btrfs Assistant the first day and scheduled snapshots for /root and /home, I have also scheduled a periodic scrub.

The app is very simple to use, but if you read the entire post, you can see that this app is not sufficient. scan (not in the app) and scrub are different things.

Personally, I appreciate a lot the btrfs functionality: snapshot, scrub, etc but unfortunately, when the error occurred, I didn’t think the system would go into readonly mode without any clues as to what to do, search discussions on this forum about btrfs readonly mode

In this situation if you use the PC for fun, you have time to understand, correct, or reformat; if you work and have deadline you’re f*ck.

Unfortunately I had to switch back to ext4, I hope they add some helpful tools for diagnosis and resolution when you encounter a problem with btrfs

Regards

18

I use mine for work too, not just “fun”. I also take time to test issues for the community at times, if my setup can accommodate it. Pointedly, my activity in this community has dropped off in the past (long) while due to more work, less “fun”.

19

File system check output is intended for the developers of the file system. They are not intended for end users. This is true of all file systems.

By the time you’re using a repair tool the damage is bad enough that there is no practical way to explain it in terms a user will understand other than “fixed” or “not fixed”.

100% of the time, upstream file system developers will want to know kernel version, storage stack description, and a full unfiltered untrimmed dmesg for the boot during which the problem occurred. This is true for all file systems. It’s not unique to Btrfs.

man btrfs check says:

   WARNING:
      Do not use --repair unless you are advised to do so by a developer...

But we do not have the either the dmesg or the btrfs check before a repair attempt was made, therefore quite a lot of information is permanently lost to make an assessment what happened or how to fix it.

Btrfs does have a more difficult time with repair. Repair shouldn’t be required in the first place because of COW, therefore something went wrong for that to fail. The overwriting file systems have fixed locations for file system metadata, and this permits assumptions to be made during repair about what should exist in those locations. That isn’t possible with Btrfs because it has no fixed locations for metadata. Repair is complex and slow. Sometimes it works, sometimes it doesn’t. But again, in general the only reason why we need repair at all in the first place with Btrfs is some sort of hardware or firmware problem.

I suggest a much longer memory test. On the ZFS and Btrfs mailing lists, we often see memtest86 variants does not detect pernicious memory defects sometimes for days of testing.

Some prefer using memtester. This is a user space memory test tool. Therefore it tests less memory than pre-boot environment testers, since the kernel and desktop environment take up a lot of memory that then cannot be tested. But booting single user mode limits the untestable footprint.

Still others prefer using gcc and compiling the kernel. This is, like btrfs, not really a memory test. It’s not going to tell you discretely that there is a memory defect and with what bank. So it’s a little suboptimal even if it will run into a problem sooner.

1 Like
20

I didn’t think the system would go into readonly mode without any clues as to what to do,

ext4, XFS, Btrfs all go read-only when they get confused, this is their default behavior. The purpose is to avoid further confusion/damage from being written to the file system.

File systems get confused when the hardware has done something unexpected, or there’s a kernel bug.

We need dmesg every single time, no matter the file system, to determine what happened. It is not possible to infer what went wrong from file system damage alone, we can only speculate.

1 Like