btrfs check for grins and giggles.

[GreyGeek]

The btrfs-check man page has

Warning
Do not use --repair unless you are advised to do so by a developer or an experienced
user, and then only after having accepted that no fsck successfully repair all types
of filesystem corruption. Eg. some other software or hardware bugs can fatally damage
a volume.

I read that as don't use --repair unless you're desperate.

So do I. BUT, if I ever get desperate I will use --repair as a last measure. Otherwise, just reformat and restore from a backup. Without a pressing need, if I did use the --repair option it would be for the same reason I tried the check option -- curiosity.

I stopped programming for pay 16 years ago, and the only programming I do now, besides using my laptop to play games, is using Python Jupyter Notebook for data analysis on covid and the calculation of satellite orbits or trajectories to distant planets, or learning AI using Python Torch and other Python modules. Nothing serious or necessary.

My serious computer work? I do my banking by an app written by my bank. I use it to keep track of my bank balance and to pay bills. I rarely log into my bank using my laptop.

[jlittle]

The btrfs-check man page has

    Warning
    Do not use --repair unless you are advised to do so by a developer or an experienced
    user, and then only after having accepted that no fsck successfully repair all types
    of filesystem corruption. Eg. some other software or hardware bugs can fatally damage
    a volume.

I read that as don't use --repair unless you're desperate.

[GreyGeek]

"man btrfs-check" gives the documentation.

I have never used the check command before. My internet M2 2880 nvme SSD was unmounted, so why not? Here are the results.

root@jerry-hp17cn1xxx:~# btrfs check -p --mode lowmem /dev/nvme0n1p1

[FONT=monospace]Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p1
UUID: 4ea5991d-7da6-4387-907d-acef20d047de
[1/7] checking root items                      (0:00:00 elapsed, 702978 items checked)
[2/7] checking extents                         (0:01:03 elapsed, 310795 items checked)
[3/7] checking free space cache                (0:00:00 elapsed, 166 items checked)
[4/7] checking fs roots                        (0:01:53 elapsed, 60210 items checked)
[5/7] checking csums (without verifying data)  (0:00:00 elapsed, 112083 items checked)
[6/7] checking root refs done with fs roots in lowmem mode, skipping
[7/7] checking quota groups skipped (not enabled on this FS)
found 164358307840 bytes used, [COLOR=#e74c3c]no error found[/COLOR]
total csum bytes: 159202256
total tree bytes: 1294565376
total fs tree bytes: 1049591808
total extent tree bytes: 61440000
btree space waste bytes: 199230567
file data blocks allocated: 191000690688
referenced 188350816256
root@jerry-hp17cn1xxx:~# [/FONT]

No errors found. That's nice. I don't need to run the "--repair" option.
The "-p" option showed the progress as it occurred and gave the output captured above.
I have only 16GB of RAM so I used the "--mode lowmem" option to keep the process from running out of RAM.

Then I decided to do a check data sum.


root@jerry-hp17cn1xxx:~# btrfs check -p --mode lowmem --check-data-csum /dev/nvme0n1p1

Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p1
UUID: 4ea5991d-7da6-4387-907d-acef20d047de
[1/7] checking root items (0:00:00 elapsed, 702978 items checked)
[2/7] checking extents (0:01:10 elapsed, 310795 items checked)
[3/7] checking free space cache (0:00:00 elapsed, 166 items checked)
[4/7] checking fs roots (0:01:54 elapsed, 60210 items checked)
[5/7] checking csums against data (0:01:25 elapsed, 112083 items checked)
[6/7] checking root refs done with fs roots in lowmem mode, skipping
[7/7] checking quota groups skipped (not enabled on this FS)
found 164358307840 bytes used, [COLOR=#e74c3c][B]no error found[/B][/COLOR]
total csum bytes: 159202256
total tree bytes: 1294565376
total fs tree bytes: 1049591808
total extent tree bytes: 61440000
btree space waste bytes: 199230567
file data blocks allocated: 191000690688
referenced 188350816256
root@jerry-hp17cn1xxx:~#

The Psensor graph showed what happened.
The first spike is when the command began. The second spike is when the check summing began. The nvme ctl chip shot up to 57C and then began falling off. At the same time, the nvme VNAND chip began climbing and flatlined at 46C.
Each vertical line is 5 minutes. So the graph shows VNAND at 46C for 18 minutes. It's now an addition a 30 minutes later and VNAND is still at 46C, so what ever the check sum triggered it has been going on for 48 minutes. I decided to mount the nvme and see if that had any effect. Immediately when I mounted it the VNAND temp dropped to 30C. Strange. If I had mounted it earlier, perhaps even as CTL reached 30C, VNAND may have dropped to 30C as well.

But, since both checks showed no errors, there was no need to use the "--repair" option.