Announcement

Collapse
No announcement yet.

btrfs check for grins and giggles.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    btrfs check for grins and giggles.

    "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

    Code:
    [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
    Code:
    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.
    Click image for larger version  Name:	psensor_btrrfs_check.png Views:	0 Size:	89.5 KB ID:	661446 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.
    Last edited by GreyGeek; Mar 15, 2022, 05:48 PM.
    "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
    – John F. Kennedy, February 26, 1962.

    #2
    The btrfs-check man page has
    Code:
        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.
    Regards, John Little

    Comment


      #3
      Originally posted by jlittle View Post
      The btrfs-check man page has
      Code:
      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.
      "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
      – John F. Kennedy, February 26, 1962.

      Comment

      Working...
      X