Aug 2 21:29:56 cybertron kernel: BTRFS error (device sdi1): bdev /dev/sdi1 errs: wr 0, rd 62020, flush 0, corrupt 0, gen 0

 

Hey Unraid team - can you tell me what this is about? New samsung ssd 1tb drive.  Ran a btrfs scrub, no errors. Smart also not reporting any issues.

 

 

 

Edited August 3, 20205 yr by repomanz

Syslog rotated so can't see start of the problem, see here to reset errors and to monitor for more in the future.

3 hours ago, johnnie.black said:

Syslog rotated so can't see start of the problem, see here to reset errors and to monitor for more in the future.

output of this btrfs dev stats /mnt/cache

root@cybertron:~# btrfs dev stats /mnt/cache
[/dev/sdg1].write_io_errs    0
[/dev/sdg1].read_io_errs     0
[/dev/sdg1].flush_io_errs    0
[/dev/sdg1].corruption_errs  0
[/dev/sdg1].generation_errs  0

I can't find it again but when was reading could be a kernel bug for read ahead?

 

Current cache is sdg, you need to adjust the mount point, what was sdi being used for? It's not on current diags, suggesting that it might have dropped or been removed since.

4 minutes ago, johnnie.black said:

Current cache is sdg, you need to adjust the mount point, what was sdi being used for? It's not on current diags, suggesting that it might have dropped or been removed since.

ok - i'm guessing I did something wrong then.   I had an ssd (formerly sdg - sandisk) that crashed. 

 

1) shutdown system

2) removed bad ssd

3) added new ssd

4) brought up system

5) stopped array

6) changed cache to the new samsung ssd

 

Did I do something wrong here?

Edited August 3, 20205 yr by repomanz

Something is wrong but like mentioned can't see the beginning of the problem, reboot and post new diags if there are still errors.

2 hours ago, johnnie.black said:

Something is wrong but like mentioned can't see the beginning of the problem, reboot and post new diags if there are still errors.

guess i needed a step 7.  reboot.  Don't see the errors in my logs anymore.  attaching diags.

 

Edited August 3, 20205 yr by repomanz

37 minutes ago, repomanz said:

guess i needed a step 7.  reboot.

It shouldn't be needed if everything was done correctly, but as long as everything's good now...

7 minutes ago, johnnie.black said:

It shouldn't be needed if everything was done correctly, but as long as everything's good now...

my steps above are correct, right? 

Also what does this mean?  Total to scrub is bad or just a metric? Ran brtfs scrub previously; came back with no errors.

 

Edited August 3, 20205 yr by repomanz

21 minutes ago, repomanz said:

my steps above are correct, right? 

Look OK if it was a a replacement without copying data from the old device.

 

22 minutes ago, repomanz said:

Total to scrub is bad or just a metric?

That refers to the used size, not device capacity.

2 minutes ago, johnnie.black said:

Look OK if it was a a replacement without copying data from the old device.

 

That's correct.  My previous SSD started reporting reported uncorrected errors, within 6 hours the drive was completely dead.    Do you have any tips on how to properly backup the VM lib and docker img files (basically containers and vm information)?  I'm already using the plugin that backs up appdata (which i restored from).

 

No need to backup the docker image, I believe that CA appdata backup already has the option to backup libvirt.

totally missed that previously. Updated now

think we're all good here.

I'm having the issue in a similar matter, the disk is passing tests and i've changed the cable, is the disk failing and so should i just RMA it back (lessthan two years old) is there seomehting somewhere else that could be causeing the issue. thanks for help in advance.

I'm running 7.0.0.

server-syslog-20250604-1312.zip

You didn't give diagnostics but an incomplete syslog, so the initial point isn't shown. But usually it's filesystem corruption rather than an issue with the drive itself, btrfs corruption is usually due to RAM problems so running a memtest would be a good idea.

Please post the full diags, but based on the syslog, one of the pool devices (/dev/sde) dropped offline.

sorry diagnotics here

I'ce correctly de attached and then re-atttached the drive - including full parity write back tot he disk, it goes for a few weeks then just drops off.

I've changed the cable in the system.

This is the thrid time it has done this.

server-diagnostics-20250604-1951.zip

Edited June 4, 20251 yr by Belcraig
new details

Jun 3 06:21:36 Server kernel: BTRFS error (device sdk1): error writing primary super block to device 2

Jun 3 06:21:36 Server kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sde1 (-5)

Jun 3 06:21:36 Server kernel: BTRFS error (device sdk1): error writing primary super block to device 2

Jun 3 06:21:36 Server kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sde1 (-5)

Jun 3 06:21:36 Server kernel: BTRFS error (device sdk1): error writing primary super block to device 2

Jun 3 06:21:36 Server kernel: BTRFS warning (device sdk1): lost page write due to IO error on /dev/sde1 (-5)

Jun 3 06:21:36 Server kernel: BTRFS error (device sdk1): error writing primary super block to device 2

Jun 3 06:21:36 Server kernel: sd 5:0:5:0: [sde] Synchronizing SCSI cache

Jun 3 06:21:36 Server kernel: sd 5:0:5:0: [sde] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK

Jun 3 06:21:36 Server kernel: scsi 5:0:5:0: rejecting I/O to dead device

This device dropped offline, check/replace its cables then scrub the pool and post the results.

ok so i noticed that when i was changing the cable that the heat sink on the card looked loose so i have also replaced the raid card - operating in HBA mode.

Parity has rebuilt the drive and the array lloks to be fine, but in a few weeks i'm expecting the drive to go again. attached are the diagnostics.

server-diagnostics-20250609-1835.zip

Scrub the pool and post the results from the GUI.

the main array you mean its an xfs filesystem, i dont think it has scrub.. do i need to repair it

i've done the cache.

UUID:             01cc169c-ab3e-4f2b-86e3-5382b85f07e7
Scrub started:    Mon Jun  9 18:57:00 2025
Status:           finished
Duration:         0:22:49
Total to scrub:   902.78GiB
Rate:             675.26MiB/s
Error summary:    verify=444 csum=285513
  Corrected:      285957
  Uncorrectable:  0
  Unverified:     0

It was just for the pool, since all errors were corrected you can reset the stats, also recommend monitoring for anymore errors:

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-700582