JorgeB

It means that block doesn't have the checksum it should have, i.e., data is corrupt, you can fix it by deleting the file or overwriting it. Most likely cause would be the SSD, there's a bad block, that was reallocated: 183 Runtime_Bad_Block PO--C- 099 099 010 - 1 The SSD firmware shouldn't reallocate a block containing data without being able to write it correctly to another place, but it's known to happen, it happened to me a few years ago with a Sandisk SSD, another option would be a one time RAM bit flip, if it was bad RAM in general it would likely cause more issues.

See if turning off hard link support in Settings/Global Share Settings helps, but you'll lose hard link support.

Yes, it's fixed for upcoming release: https://forums.unraid.net/bug-reports/prereleases/68-rc1-kernel-tun-unexpected-gso-r634/?do=findComment&comment=8945

Posting the diagnostics might also give some clues.

Like mentioned if the same filesystem keeps getting corrupt I would create a new one.

Diags are after rebooting so not much to look at, try this and post the syslog after the problem occurs again.

Please remind us of current array status, or just post a screenshot of main.

Should be soon(™), lots of work to get multiple pools working as problem free and safely as possibly from the get go, likely much more than anticipated.

Diags are after rebooting so can't see what caused the problem but that's not how you use xfs_repair, not against the device or you'll invalidate parity, and it's missing the partition anyway, see here: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

It's failing to get device capacity: May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08 May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] Sense Key : 0x2 [current] [descriptor] May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] ASC=0x4 ASCQ=0x0 May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=0x08 May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] Sense Key : 0x2 [current] [descriptor] May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] ASC=0x4 ASCQ=0x0 May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] 0 512-byte logical blocks: (0 B/0 B) May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] 0-byte physical blocks May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] Test WP failed, assume Write Enabled May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] Asking for cache data failed May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] Assuming drive cache: write through May 9 07:50:41 Tower kernel: sd 7:0:0:0: [sde] Spinning up disk... May 9 07:52:22 Tower kernel: ..................................................................................................not responding... May 9 07:52:22 Tower kernel: sd 7:0:0:0: [sde] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08 May 9 07:52:22 Tower kernel: sd 7:0:0:0: [sde] Sense Key : 0x2 [current] [descriptor] May 9 07:52:22 Tower kernel: sd 7:0:0:0: [sde] ASC=0x4 ASCQ=0x0 May 9 07:52:22 Tower kernel: sd 7:0:0:0: [sde] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=0x08 May 9 07:52:22 Tower kernel: sd 7:0:0:0: [sde] Sense Key : 0x2 [current] [descriptor] May 9 07:52:22 Tower kernel: sd 7:0:0:0: [sde] ASC=0x4 ASCQ=0x0 May 9 07:52:22 Tower kernel: sd 7:0:0:0: [sde] Attached SCSI disk Try updating the LSI firmware since it's on a very old one, if still issues might be the disk, after the update try to get a SMART report since current one is incomplete.

No, that's not what it says in the FAQ, if says to be careful with --repair because some times it can make things even worse, if you had already backed up the data using one of the other methods it's OK to try --repair (or if none of the other methods worked) since you have nothing to lose, but there's also a chance that a repaired filesystem might run into issues again in the near future, depends on what the problem was, so make sure backups are up to date and if it gets corrupt again soon best to re-format.

Some questions are difficult to answer, it depends on the exact circumstances, I can answer some: Yes, parity checks should always be non correct unless sync errors are expected, like after an unclean shutdown for example. No usually, but always download diags before rebooting if there were issues/errors. If you have doubts download the diags and ask for help in the forum before doing anything else. Unraid is never a backup, it does give you some redundancy but many other things can happen, user error, ransomware, fs corruption, etc, you need to have backups of anything important or irreplaceable.

Might be easier to see what's causing them if the syslog covers the start of the issue.

First rule out bad RAM since that could be the reason for multiple fs corruptions, if no errors are found I would try re-formatting that disk to create a new filesystem, but you need to back it up first.

You can restore the backup.

Memtest won't work with UEFI boot, only legacy BIOS/CSM.

Recreate the flash drive and restore the config folder, I'm not familiar with the linux make_bootable, if you can get your hands on a Win10 PC you can use the USB tool which makes it easier.

The problem likely resulted from this, but can't say more without diags.

Then that suggests parity wasn't 100% valid, or something else happened before the replacement, the diags just show after you replaced the disk, did you save the old ones by chance?

Was the disk disabled before you replaced it? And if yes was the emulated disk mounting correctly?

The syslog posted is filled with crashes, but I can't see the beginning of the problem or parity checks, reboot, start a parity, let it finish, do another one, then post diags, without rebooting.

That's about it.

Drive failure not the same as filesystem corruption, Unraid can only help with the former, though sometimes a drive failing might corrupt the filesystem.

Then you might have something trying to use that SSD/port, like a VM.

It won't wok if was formatted, you didn't need to format, just: