not zero on folio

[francoism90]

[   75.164771] BTRFS error (device dm-5): failed to read chunk tree: -2
[   75.165515] _btrfs_printk: 160 callbacks suppressed
[   75.165517] BTRFS warning (device dm-5): folio private not zero on folio 22036480
[   75.165519] BTRFS warning (device dm-5): folio private not zero on folio 22040576
[   75.165521] BTRFS warning (device dm-5): folio private not zero on folio 22044672
[   75.165523] BTRFS warning (device dm-5): folio private not zero on folio 22048768
[   75.165524] BTRFS warning (device dm-5): folio private not zero on folio 22052864
[   75.165526] BTRFS warning (device dm-5): folio private not zero on folio 22056960
[   75.165527] BTRFS warning (device dm-5): folio private not zero on folio 22061056
[   75.165529] BTRFS warning (device dm-5): folio private not zero on folio 22065152
[   75.165531] BTRFS warning (device dm-5): folio private not zero on folio 22151168
[   75.165532] BTRFS warning (device dm-5): folio private not zero on folio 22155264
[   75.165534] BTRFS warning (device dm-5): folio private not zero on folio 22159360
[   75.165535] BTRFS warning (device dm-5): folio private not zero on folio 22163456

This happend after latest btrfs-progs upgrade on Fedora 40.

Is my data gone? :/

[francoism90]

Hmm, so after changing the UUID in /etc/fstab to another UUID (RAID-0/bigdata), it works again and I can mount the FS.

Is this expected?

[kdave]

This is a kernel issue and btrfs-progs don't affect that.

[kdave]

BTRFS error (device dm-5): failed to read chunk tree: -2 this is strange, -2 is ENOENT, chunk tree not found means there's not a device found that contains part of the data that are needed for mount, this is expected for raid0 as it's striped IF there's either a missing device or something like a device overwrite while still mounted. What is the kernel version?

[adam900710]

Firstly the folio not zero just means we didn't properly cleanup the metadata.

The root cause is just as mentioned by David, that chunk tree read failed. We can improve the error handling, but the reason why is still unclear (I guess there are some extra lines before that chunk read failure line?)

[francoism90]

@kdave @adam900710 Sorry about not fully providing the dmesg log, but it indeed complained about missing drives (cannot find UUID of - or something like that).

I'm running Fedora 40 Silverblue:

$ uname -a                                                                                                                  
Linux desktop 6.8.8-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Apr 27 17:53:31 UTC 2024 x86_64 GNU/Linux

I assumed it was btrfs-progs, as this was the only package that was upgraded before rebooting:

$ rpm-ostree db diff
ostree diff commit from: rollback deployment (f1a02a26792ce05db1f273b5fd6367140737f462632fd9f6def130c38be54796)
ostree diff commit to:   booted deployment (269a6a6f0475bca21958ebc4a2de14cf2b2c645654dd4ddc03dd67eaaab3a302)
Upgraded:
  btrfs-progs 6.8-1.fc40 -> 6.8.1-1.fc40
  default-editor 7.2-6.fc40 -> 7.2-7.fc40
  evince-djvu 46.0-1.fc40 -> 46.1-1.fc40
  evince-libs 46.0-1.fc40 -> 46.1-1.fc40
  evince-previewer 46.0-1.fc40 -> 46.1-1.fc40
  evince-thumbnailer 46.0-1.fc40 -> 46.1-1.fc40
  fwupd 1.9.16-1.fc40 -> 1.9.19-1.fc40
  fwupd-plugin-flashrom 1.9.16-1.fc40 -> 1.9.19-1.fc40
  fwupd-plugin-modem-manager 1.9.16-1.fc40 -> 1.9.19-1.fc40
  fwupd-plugin-uefi-capsule-data 1.9.16-1.fc40 -> 1.9.19-1.fc40
  gtk4 4.14.3-1.fc40 -> 4.14.4-1.fc40
  libbsd 0.12.2-1.fc40 -> 0.12.2-3.fc40
  libphonenumber 8.13.33-1.fc40 -> 8.13.35-1.fc40
  nano 7.2-6.fc40 -> 7.2-7.fc40
  nano-default-editor 7.2-6.fc40 -> 7.2-7.fc40
  vte-profile 0.76.0-1.fc40 -> 0.76.1-1.fc40
  vte291 0.76.0-1.fc40 -> 0.76.1-1.fc40

[francoism90]

I just realize something: to make each disk suspend I've adjusted the timer with Gnome Disks, which seems to write changes to /etc/fstab (even when not changing any mount flags).

It's weird, because it states this about /etc/fstab:

-rw-r--r--. 1 root                 root                   1531 15 apr 13:35 fstab

I have changed the /etc/fstab file yesterday to make it work again. I also added extra comments so I could trace the old UUIDs, which now seems gone as well (my own mistake, should had copy to a different file instead).

I have no idea if Gnome Disk is changing these values, or something else. But it happened later, as I'm sure I've booted with those comments still in /etc/fstab.

Is it possible to trace which process changed /etc/fstab?

[francoism90]

I'll close this issue, as it seems to be related to GD, and not btrfs-progs.

Thanks for looking into this!