Btrfs check errors

Hi, I have run # btrfs scrub start / and when completed btrfs scrub status / shows:
UUID: 605560ad-fe93-4d09-8760-df0725b43ee1
Scrub started: Mon Feb 26 18:53:39 2024
Status: finished
Duration: 0:15:01
Total to scrub: 134.35GiB
Rate: 152.68MiB/s
Error summary: no errors found

Then btrfsck --check --force /dev/mapper/system-root displays a very long list of errors of various sorts. It seems like more errors have accumulated within the past weeks. Here are is the list of the various errors: openSUSE Paste

Do you know what is going on with all these errors? Are they serious problems and can they be repaired somehow? Why did this happen?

1 Like

You are checking a file system that is mounted and in use. So the errors might not mean anything.

If you still have your install media, boot to the rescue system and check the ā€œbtrfsā€ file system while it is not mounted.

2 Likes

I wouldnā€™t hold out much hope for scrub.
Even when my btrfs filesystem was completely hosed due to one too many kernel panics, scrub didnā€™t find any issues :grimacing:

btrfs check on a rescue system did though:

man 8 btrfs-check cautions severely against using the --repair option, so even if you find errors youā€™re better off re-creating a new btrfs filesystem and restoring your data from backups.

From Hardware as the main source of filesystem corruptions

ā€œIf you use unreliable hardware and donā€™t know about that, donā€™t blame the filesystem when it tells you.ā€

Infamous host erlangen has the following file systems:

erlangen:~ # btrfs filesystem show 
Label: 'System'  uuid: 0e58bbe5-eff7-4884-bb5d-a0aac3d8a344
        Total devices 1 FS bytes used 804.78GiB
        devid    1 size 1.82TiB used 832.06GiB path /dev/nvme1n1p2

Label: 'Data'  uuid: 0e9f8bb1-2e36-4a6e-aab8-50a12a269d37
        Total devices 1 FS bytes used 1.20TiB
        devid    1 size 1.82TiB used 1.20TiB path /dev/sda1

Label: 'Backup'  uuid: 8a723ba5-c46f-45df-b708-0cf9c541da27
        Total devices 1 FS bytes used 621.55GiB
        devid    1 size 1.82TiB used 634.07GiB path /dev/nvme0n1p2

erlangen:~ # 

Performed a check of all three systems. System and Backup showed errors while Data was clean.

Note: btrfs balance works fine on mounted file systems, even on a running system partition while btrfs check --repair requires unmounting.

System was fixed by running btrfs balance start -m /. This wouldnā€™t work for Backup. A full balance btrfs balance start /Backup relocated some chunks but eventually stopped on encountering a missing block:

erlangen:~ # journalctl -g btrfs -p3
Feb 28 07:51:16 erlangen kernel: BTRFS error (device nvme0n1p2): couldn't find block (412207087616) (level 1) in tree (2405) with key (650 96 3847)
erlangen:~ # 

Running btrfs check --repair /dev/nvme0n1p2 made Backup great again:

erlangen:~ # btrfs check /dev/nvme0n1p2 
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p2
UUID: 8a723ba5-c46f-45df-b708-0cf9c541da27
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 666533203968 bytes used, no error found
total csum bytes: 642589584
total tree bytes: 8037629952
total fs tree bytes: 6820233216
total extent tree bytes: 479035392
btree space waste bytes: 1617186424
file data blocks allocated: 22037086281728
 referenced 2007090851840
erlangen:~ # 
1 Like

hmmm. no feedback from OP, two days later ? Important? :slight_smile:

Thank you for your insight on this. I have been reviewing this and other information more deeply.

I will report back.

Hi, after running scrub start / it completes without error. Then I was able to unmount the filesystem and btrfsck check --readonly /dev/mapper/system-root it completes with errors found. Then mounting the filesystem and balancing with btrfs balance start /it completes and turns the filesystem into read-only (ro). I have uploaded the btrfs check and dmesg output for review here ā†’ http://cwillu.com:8080/65.128.157.101 numbers 3 and 4 of 1-4 are the important error logs.

Please do note that once screenlock activates I can no longer access the desktop and must powercycle. Well actually pull the cord out of PSU because the machine locks up and keyboard light indicators flash during shutdown.

Upon a reboot the mountcommand displays the following in konsole:

Thinkcentre-M57p:~> mount
/dev/mapper/system-root on / type btrfs (ro,relatime,space_cache,subvolid=1553,subvol=/@/.snapshots/1110/snapshot)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=4096k,nr_inodes=975302,mode=755,inode64)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=1575584k,nr_inodes=819200,mode=755,inode64)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=5638)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64)
/dev/mapper/system-root on /.snapshots type btrfs (ro,relatime,space_cache,subvolid=266,subvol=/@/.snapshots)
/dev/mapper/system-root on /boot/grub2/i386-pc type btrfs (ro,relatime,space_cache,subvolid=265,subvol=/@/boot/grub2/i386-pc)
/dev/mapper/system-root on /boot/grub2/x86_64-efi type btrfs (ro,relatime,space_cache,subvolid=264,subvol=/@/boot/grub2/x86_64-efi)
/dev/mapper/system-root on /srv type btrfs (ro,relatime,space_cache,subvolid=260,subvol=/@/srv)
/dev/mapper/system-root on /opt type btrfs (ro,relatime,space_cache,subvolid=262,subvol=/@/opt)
/dev/mapper/system-root on /usr/local type btrfs (ro,relatime,space_cache,subvolid=259,subvol=/@/usr/local)
/dev/mapper/system-root on /home type btrfs (ro,relatime,space_cache,subvolid=263,subvol=/@/home)
/dev/mapper/system-root on /root type btrfs (ro,relatime,space_cache,subvolid=261,subvol=/@/root)
/dev/mapper/system-root on /var type btrfs (ro,relatime,space_cache,subvolid=258,subvol=/@/var)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=787792k,nr_inodes=196948,mode=700,uid=1000,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
Thinkcentre-M57p:~>

-Thanks

:dizzy_face:

Itā€™s mounted as read-only, which is probably good to avoid further data loss.
Clone the drive from a rescue ISO, then mount it as read-only and take a backup of the subvolumes.
Then re-create the btrfs fs and the subvolumes and restore the data from the backup.

You should fix the kernel panic before doing this though, once you have the clone/copy feel free to run check --repair on the fs as well. Perhaps that might enable you to read-write mount it.

:cold_face:

The good thing is that this drive (I have been discussing) is not the primary drive. It is a backup drive of my primary drive. I am trying to fix the issues obviously. The primary drive is an ssd drive while the backup (the mentioned drive) is mechanical platter based.

Iā€™ve been told to send to logs (mentioned above) to: majordomo@vger.kernel.org
An obsoleted list which page is obsolete located here: https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list.html#Restrictions

I was told that the problem is deep and the list would never respond but the message meta will be scanned and possibly used for a kernel or bug report in the future, I have created my message and posted to the list mentioned as of now. Initially my GMX email account would not allow me to post to the list but I then resorted to using Thunderbird with a different GMX email account associated and it seems to have been sent correctly.

I have been told this yes. It appears this may be my only alternative for proper repair. I do not know how to fix the kernel panic firstly as it seems associated with the btrfs balance issue.

1 Like

Relax!

The ThinkCentre obviously ran into a severe problem with btrfs. On the other hand @christomonte11 successfully installed and maintains Tumbleweed on several of his ThinkPads w530:

root@linux-server1: ~
# inxi -zSCMm
System:
  Kernel: 6.7.6-1-default arch: x86_64 bits: 64
  Console: pty pts/3 Distro: openSUSE Tumbleweed 20240227
Machine:
  Type: Laptop System: LENOVO product: 2447K70 v: ThinkPad W530 serial: <filter>
  Mobo: LENOVO model: 2447K70 serial: <filter> UEFI: LENOVO v: G5ET96WW (2.56 ) date: 11/27/2013
Memory:
  System RAM: total: 32 GiB available: 31.17 GiB used: 8.54 GiB (27.4%) igpu: 64 MiB
  Array-1: capacity: 32 GiB slots: 4 modules: 4 EC: None
  Device-1: ChannelA-DIMM0 type: DDR3 size: 8 GiB speed: 1600 MT/s
  Device-2: ChannelA-DIMM1 type: DDR3 size: 8 GiB speed: 1600 MT/s
  Device-3: ChannelB-DIMM0 type: DDR3 size: 8 GiB speed: 1600 MT/s
  Device-4: ChannelB-DIMM1 type: DDR3 size: 8 GiB speed: 1600 MT/s
CPU:
  Info: quad core model: Intel Core i7-3740QM bits: 64 type: MT MCP cache: L2: 1024 KiB
  Speed (MHz): avg: 1213 min/max: 1200/3700 cores: 1: 1265 2: 1200 3: 1200 4: 1198 5: 1197
    6: 1251 7: 1200 8: 1200

root@linux-server1: ~
# 

The systems use minimal partitioning with a single btrfs partition and are running rock stable; sda3 is a backup system not used during normal operation:

 root@linux-server1: ~
# fdisk -l
Disk /dev/sda: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Samsung SSD 850 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F419ACF3-57E2-451C-8979-74789CF5F923

Device         Start        End   Sectors   Size Type
/dev/sda1       2048    1050623   1048576   512M EFI System
/dev/sda2    1050624  874385407 873334784 416.4G Linux filesystem
/dev/sda3  874385408 1000215182 125829775    60G Linux filesystem

root@linux-server1: ~
# 

You may show the above information for your system.

1 Like

Thanks for the strong words of comfort. I have recloned from primary so I do have at least a backup now once again in most certain case of btrfs balance creating read only filesystem if run again. I am now operating the machine once again with the primary drive installed.

Thinkcentre-M57p:~ # inxi -zSCMm
System:
  Kernel: 6.7.6-1-default arch: x86_64 bits: 64
  Console: pty pts/4 Distro: openSUSE Tumbleweed 20240225
Machine:
  Type: Desktop System: LENOVO product: 9088A83 v: ThinkCentre M57p
    serial: <filter>
  Mobo: LENOVO model: LENOVO serial: N/A BIOS: LENOVO v: 2RKT64BUS
    date: 01/08/2014
Memory:
  System RAM: total: 8 GiB available: 7.51 GiB used: 3.78 GiB (50.4%)
  Array-1: capacity: 8 GiB slots: 4 modules: 4 EC: None
  Device-1: DIMM 0 type: DDR2 size: 2 GiB speed: 667 MT/s
  Device-2: DIMM 1 type: DDR2 size: 2 GiB speed: 667 MT/s
  Device-3: DIMM 2 type: DDR2 size: 2 GiB speed: 667 MT/s
  Device-4: DIMM 3 type: DDR2 size: 2 GiB speed: 667 MT/s
CPU:
  Info: quad core model: Intel Core2 Quad Q8400 bits: 64 type: MCP cache:
    L2: 4 MiB
  Speed (MHz): avg: 2333 min/max: 2000/2667 cores: 1: 2667 2: 2000 3: 2000
    4: 2667
Thinkcentre-M57p:~ #

ā€“

Thinkcentre-M57p:~ # fdisk -l


Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC  WDS100T2B0A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 67AAD724-4E3B-4DBB-B4BB-176D1E16FE72

Device     Start        End    Sectors   Size Type
/dev/sda1   2048      18431      16384     8M BIOS boot
/dev/sda2  18432 1953523711 1953505280 931.5G Linux LVM


Disk /dev/mapper/Lenovo_M57p-openSUSE_Tumbleweed: 931.5 GiB, 1000192606208 bytes, 1953501184 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/system-swap: 15.52 GiB, 16659775488 bytes, 32538624 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/system-root: 915.98 GiB, 983530733568 bytes, 1920958464 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Thinkcentre-M57p:~ #

Your hardware is ancient, but it should still work satisfactorily. Consider an upgrade to Skylake or newer with ample memory.

What about the HDD? Thorough testing by moving and shaking allocated chunks is a great way to sort out drives which pretend to work still satisfactorily under ext4 but actually report trouble when checked with btrfs.

1 Like

Hi, I initially cloned this current drives btrfs filesystem from a mechanical 160 GB drive to the 1 TB SSD (used now and discussed above). Then expanded the partition, extended the LVG (system-root) and finally the btrfs filesystem. Scrub never reports an error so far. Maybe this drive does fail that given sanity check?

A memtest with 4 completed passes ran last 24 hours with no errors. The information you share is of interest.

I have been told that turning off quota can eliminate errors but slow the drive. With the drive unmounted btrfs check --readonly reports the following errors 60 hours ago:

[1/7] checking root items 
[2/7] checking extents 
[3/7] checking free space cache 
[4/7] checking fs roots 
[5/7] checking only csums items (without verifying data) 
[6/7] checking root refs 
[7/7] checking quota groups 
ERROR: failed to add qgroup relation, member=1212 parent=281474976710656: No such file or directory 
ERROR: loading qgroups from disk: -2 
ERROR: failed to check quota groups extent buffer leak: start 156676964352 len 16384 
extent buffer leak: start 155760427008 len 16384 Opening filesystem to check... Checking filesystem on /dev/mapper/system-root UUID: 605560ad-fe93-4d09-8760-df0725b43ee1 found 142244990976 bytes used, error(s) found total csum bytes: 133137492 total tree bytes: 2885664768 total fs tree bytes: 2632204288 total 
extent tree bytes: 86687744 btree space waste bytes: 711984982 file data blocks allocated: 487941488640 referenced 456996900864

I have been told to use btrfs check --readonly when drive is unmounted. I have attempted to run btrfs check --force on the drive with different output results usually each time.

Thinkcentre-M57p:~ # btrfs filesystem show
Label: none  uuid: 605560ad-fe93-4d09-8760-df0725b43ee1
        Total devices 1 FS bytes used 134.80GiB
        devid    1 size 915.98GiB used 152.07GiB path /dev/mapper/system-root
Thinkcentre-M57p:~> sudo smartctl -A /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.7.6-1-default] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 4
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   ---    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   ---    Old_age   Always       -       39087
 12 Power_Cycle_Count       0x0032   100   100   ---    Old_age   Always       -       528
165 Block_Erase_Count       0x0032   100   100   ---    Old_age   Always       -       3480214390199
166 Minimum_PE_Cycles_TLC   0x0032   100   100   ---    Old_age   Always       -       333
167 Max_Bad_Blocks_per_Die  0x0032   100   100   ---    Old_age   Always       -       26
168 Maximum_PE_Cycles_TLC   0x0032   100   100   ---    Old_age   Always       -       403
169 Total_Bad_Blocks        0x0032   100   100   ---    Old_age   Always       -       492
170 Grown_Bad_Blocks        0x0032   100   100   ---    Old_age   Always       -       0
171 Program_Fail_Count      0x0032   100   100   ---    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   ---    Old_age   Always       -       0
173 Average_PE_Cycles_TLC   0x0032   100   100   ---    Old_age   Always       -       373
174 Unexpected_Power_Loss   0x0032   100   100   ---    Old_age   Always       -       162
184 End-to-End_Error        0x0032   100   100   ---    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   ---    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   ---    Old_age   Always       -       5
194 Temperature_Celsius     0x0022   073   055   ---    Old_age   Always       -       27 (Min/Max 15/55)
199 UDMA_CRC_Error_Count    0x0032   100   100   ---    Old_age   Always       -       0
230 Media_Wearout_Indicator 0x0032   037   037   ---    Old_age   Always       -       0x2345251e251e
232 Available_Reservd_Space 0x0033   100   100   004    Pre-fail  Always       -       100
233 NAND_GB_Written_TLC     0x0032   100   100   ---    Old_age   Always       -       378806
234 NAND_GB_Written_SLC     0x0032   100   100   ---    Old_age   Always       -       424619
241 Host_Writes_GiB         0x0030   253   253   ---    Old_age   Offline      -       156040
242 Host_Reads_GiB          0x0030   253   253   ---    Old_age   Offline      -       130071
244 Temp_Throttle_Status    0x0032   000   100   ---    Old_age   Always       -       0

Thinkcentre-M57p:~>

Perhaps the hardware is indeed the culprit in this situation. I just do not see any issues with the journal output of the drive personally.

What is going on here?

-Greatest Wishes

The Data disk is mounted, but no data are written:

erlangen:~ # time btrfs check --force --check-data-csum --progress /dev/sda1
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/sda1
UUID: 0e9f8bb1-2e36-4a6e-aab8-50a12a269d37
[1/7] checking root items                      (0:00:00 elapsed, 201926 items checked)
[2/7] checking extents                         (0:00:04 elapsed, 96910 items checked)
[3/7] checking free space tree                 (0:00:00 elapsed, 1234 items checked)
[4/7] checking fs roots                        (0:00:00 elapsed, 3354 items checked)
[5/7] checking csums against data              (1:01:25 elapsed, 162018 items checked)
[6/7] checking root refs                       (0:00:00 elapsed, 3 items checked)
[7/7] checking quota groups                    (0:00:00 elapsed, 6716 items checked)
found 1317428645888 bytes used, no error found
total csum bytes: 1285001012
total tree bytes: 1587609600
total fs tree bytes: 55132160
total extent tree bytes: 16351232
btree space waste bytes: 226068639
file data blocks allocated: 1315841036288
 referenced 1315836633088

real    61m32.934s
user    2m45.877s
sys     4m55.572s
erlangen:~ # 

Checksums are consistent, quota too. They are optional and suck if enabled, but unused. You may safely disable them and rerun your check with --check-data-csum.

Hey, I would like to ask you what the ā€˜timeā€™ is in your command above? I havenā€™t seen that one yet.

Just so we are also on the same page with this. Tell me please how you disable quota? Quota was enabled by default here since system birth I think.

Ok, I see # btrfs quota disable . Do you recommend usually to do this with all btrfs drives yourself?

Update, I was just told the following below.
Never use --force with check
You donā€™t need --check-data-csum, btrfs scrub will do that much faster

What are your thoughts about this?

281474976710656 == 0x1000000000000

so it does sounds like bitflip (assuming it expected zero at this point). You better ask on btrfs list.

I donā€™t use quota on any filesystem. Thus they are disabled on all.

You can trust this if no error messages are printed. If errors occur they could be false positives.

You can use this option. On Data this takes 1:01:25. btrfs scrub is 50% faster:

erlangen:~ # btrfs scrub status /home_SSD
UUID:             0e9f8bb1-2e36-4a6e-aab8-50a12a269d37
Scrub started:    Sat Mar  2 07:16:27 2024
Status:           finished
Duration:         0:41:26
Total to scrub:   1.20TiB
Rate:             506.00MiB/s
Error summary:    no errors found
erlangen:~ # 

However scrub is an online maintenance procedure and supports throttling.

A quick check is really fast:

erlangen:~ # time btrfs check --force --progress /dev/sda1
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/sda1
UUID: 0e9f8bb1-2e36-4a6e-aab8-50a12a269d37
[1/7] checking root items                      (0:00:00 elapsed, 201928 items checked)
[2/7] checking extents                         (0:00:04 elapsed, 96910 items checked)
[3/7] checking free space tree                 (0:00:00 elapsed, 1235 items checked)
[4/7] checking fs roots                        (0:00:00 elapsed, 3354 items checked)
[5/7] checking csums (without verifying data)  (0:00:00 elapsed, 162018 items checked)
[6/7] checking root refs                       (0:00:00 elapsed, 3 items checked)
[7/7] checking quota groups skipped (not enabled on this FS)
found 1317428662272 bytes used, no error found
total csum bytes: 1285001012
total tree bytes: 1587625984
total fs tree bytes: 55132160
total extent tree bytes: 16384000
btree space waste bytes: 226080967
file data blocks allocated: 1315841036288
 referenced 1315836633088

real    0m4.624s
user    0m0.973s
sys     0m0.647s
erlangen:~ # 
1 Like

Regular memtest will not find issues with video RAM.
It also will not find issues when a perfectly fine module is ā€œincompatibleā€ with the onboard graphics if said graphics uses the normal RAM for its VRAM (video memory).

I had the latter problem causing my PC to crash, which eventually lead to btrfs failure that not even the repair function could fix. All this time, scrub never found an issue. If your memory is bad, thereā€™s not much btrfs or zfs can do to fix that I suppose.

Run memtest vulkan and glmark2 to get a read on whether the graphics end of things are working fine.

1 Like

transactional update upgrades the backup system and tries to reboot. A scrub wants to continue. Pressing the reset button during scrub on the backup system results in:

erlangen:~ # journalctl --directory /Backup/@/var/log/journal/ --boot -2 --unit btrfs-scrub.service --output short-monotonic 
[    8.253491] backup systemd[1]: Started Scrub btrfs filesystem, verify block checksums.
[    8.256791] backup btrfs-scrub.sh[1302]: Running scrub on /
[  200.390674] backup systemd[1]: Stopping Scrub btrfs filesystem, verify block checksums...
[  290.552836] backup systemd[1]: btrfs-scrub.service: State 'final-sigterm' timed out. Killing.
[  290.553274] backup systemd[1]: btrfs-scrub.service: Killing process 1321 (btrfs) with signal SIGKILL.
[  290.553324] backup systemd[1]: btrfs-scrub.service: Killing process 1325 (btrfs) with signal SIGKILL.
erlangen:~ # 

Presumably reset is ignored. Scrub times out and is killed without further ado.