JorgeB

The netbook I had the same problem also had little RAM, just can't be certain now if it was 1 or 2GB, but most likely only 1GB also.

Don't ask me how it works, I can only tell you that it worked for me on a netbook that without that wouldn't boot any release after 6.4

Try this, it worked for me for an identical error, on the flash drive edit syslinux/syslinux.cfg and add root=sda to the boot option you're using after initrd=/bzroot, e.g.: label Unraid OS menu default kernel /bzimage append initrd=/bzroot root=sda

This should have been posted on the general support forum since it's not v6.6.6 related, disks look fine, looks more like a connection issue, you're also using IDE mode which can cause problems, change the controller to AHCI in the bios, check/replace cables and rebuild the disabled disk.

That's likely the best way, you can also keep -a and just add the --no-perms flag, e.g.: rsync -av --no-perms etc

The problem isn't Unraid, the problem is that you can have memory errors if overclocking the RAM with Ryzen CPUs, several cases on the forum where users were having sync errors on the parity check because of that, IMO, if you care about the data on the server, limit you RAM speeds to max officially supported without overclocking:

Do you have an older non UEFI computer you could use? That's what I do for all my flashing, if not wait for someone with UEFI flash experience to help.

Are you on latest releases? v6.6.6? If not upgrade.

Yes

Maybe the same issue as this one?

That doesn't mean anything, Samsung supports read zero after trim, Crucial doesn't, so for example the Samsung would work on some LSI controllers, the Crucial won't, but it will work on the onboard SATA ports.

Likely it's on a controller that doesn't support trim, use the onboard SATA ports for the SSD

For this to have any meaning you need to disable compression for the pool before testing, zeros are highly compressible.

Yeah, until there's a functional fsck for btrfs anytime there's fs corruption backup, format, restore should be the default action.

Basically btrfs --repair should only be used if told so by a btrfs maintainer or somebody else very experienced using it, and I don't consider myself one, if cache is unmountable you can use this to help with backup, reformat and restore, to really try to repair the fs you'd need to ask for help on the btrfs mailing list.

You should be able to delete the small partition using diskpart (command line in windows)

AFAIK that was never the problem, the issue is the ZFS licence.

That attribute wasn't monitored by the older release you were using, just acknowledge it, you only need to worry about it if it keeps increasing.

From what I understand this works best when the SSD is mostly empty, still it should be able to sustain around 400/450MB/s even when the SLC cache is exhausted.

The larger models have more dies and can spread the writes in parallel, hence why they are faster, though I meant the 500GB models are the smallest capacity that can sustain 500GB/s, this for the Samsung 850 or 860EVO, the Crucial MX500 should be similar, around 400/450MB for the 500GB model, e.g. this is for the 850EVO, 860EVO is similar: https://www.anandtech.com/show/8747/samsung-ssd-850-evo-review/2 Turbowrite is the small SLC cache that lasts for a few seconds only, after that speed will decrease a lot for the smallest capacity models.

They can write up to 500MB/s, only when the SLC cache is empty, once that is exhausted speed are much slower, though I would still expect better then 100MB/s, but clearly they are what's limiting you're speed. IMO the MX500 and 860EVO are currently the best, though only the 1TB capacities can sustain 500MB/s writes.

The command redirects the log to that file, unfortunately don't see anything there crash related.

That explains it.

Is there nothing on taillog.txt?