I used to overclock the raspberry pi 400 to 2 GHz (instead of 1.8 GHz) with overvoltage. Maybe overvoltage leads to RAM corruption that got written to the btrfs metadata.
I try to write the essentials from discussions in #gentoo-arm and #btrfs at irc.libera.chat
Repair and recover
- A journal replay is acceptable to some people and didn't get any back talk.
- If a filesystem would be in a normal, repairable state, it would be easy for the fs to just auto fix it. There is a difference between being able to read the data and to mount it. Repairing a fs to make it mountable can lead to data loss and should not be the preferred method. A btrfs check init-csum-tree doesn't give you the same safety as recover and mkfs. Even if it would be faster to repair then to rebuild the fs, there could still be memory corruption.
- Recovering data is a wider accepted way, but you have to keep in mind, that the data may be corrupted, since e.g. the btrfs restore doesn't verify the checksums.
The btrfs.fsck is just an empty command. In the man page of btrfs-check there are several options listed to repair a btrfs but it isn't recommended to use them. It is recommended to recover the data and use mkfs to get a clean fs.
- There is no label tool, the label has to be set when creating the fs.
- There are unfixed bugs like https://bugs.gentoo.org/681618 "sys-fs/f2fs-tools-1.12.0-r1 fails to fsck rootfs on boot"
- The fsck.fat doesn't repair but just changes the dirty bit.
insecure and fast options
The mq-deadline scheduler supports some insecure options to tweak the speed.
[mq-deadline] kyber none
DEVICE="sda" echo 64000 > /sys/block/$DEVICE/queue/iosched/fifo_batch echo 6000 > /sys/block/$DEVICE/queue/iosched/read_expire echo 60000 > /sys/block/$DEVICE/queue/iosched/write_expire mount -o remount,commit=3600 /