JorgeB

Same as the current cache pool, they are independent filesystems.

You are talking about what's usually called bit rot, and while that exists it's extremely rare, all disks have ECC checking and should never return bad data, they either return good data or give a read error, like UNC @ LBA, there are exceptions due to bad firmware or onboard DRAM going bad but like mentioned these are extremely rare and no way a possibility with the frequency you describe, you likely have a serious hardware problem, unless you're using ECC RAM that would be the prime suspect, but could also be a bad controller, etc, certainly not the disks, maybe if it was always the same disk doing it. I've encountered it once, with a Sandisk SSD, that silent corrupted data after a sector remapping, I have over 200 disks on my servers, besides the manual checksums all my disks are formatted with btrfs or ZFS, that have their own checksum and can detect silent data corruption on all reads or with a scrub, and like mentioned it never happened (except that SSD, and the corruption was immediately caught by btrfs).

The more logical explanations are either the error comes from another share or the cache was fuller at some point in time, your syslog is heavily spammed with various errors and there's time missing, you can reboot, run the mover again a post new diags.

It can be confusing, but any LSI that has MegaRAID in the model name can be left off the buy list.

That's fine, I was just pointing out that multiple pools are a reality, not a rumor or unconfirmed.

They are already available on v6.9-beta22.

You are correct that disks usually don't error on writes, they mostly error on reading back the data, but that would be fixed by Unraid's redundancy (assuming you have parity), if the mover had to read back all writes it would take twice as long, and the disks can still fail at any time after that, so it would not be a garantee that you could still the read the same data tomorrow.

Sorry, no idea, never had Adaptec HBAs, though I know some users are using them with Unraid, but don't remember the specif models, you can try searching the forum.

Checksum verifications are a read operation.

This refers to the share being written to minimum space setting (i.e. cache has less free space than the share's minimum free space setting), when the cache device/pool itself is full (i.e. hitting the cache floor setting) you get: shfs: cache disk full

There are 16 port versions of some of the models posted, I only list the 8 ports models since they are the most wanted, but look for LSI models ending in -16i

Mostly btrfs send/receive and some rsync, both over SSH witch in itself is not great for speed, but still much better than gigabit.

Thanks for reporting back, going to mark this as solved.

No, but I've also moved 100's of TBs and never had a single checksum error, I don't use teracopy but I create checksums with corz while still on my desktop and from atime to time run a complete check on the server, all checksums still match.

👍

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=537383

I'm not familiar with that controller, but it's a RAID controller, so likely not a good option, look for any LSI with a SAS2008/2308/3008/3408 chipset in IT mode, e.g., 9201-8i, 9211-8i, 9207-8i, 9300-8i, 9400-8i, etc and clones, like the Dell H200/H310 and IBM M1015, these latter ones need to be crossflashed.

Docker image is on disk1, and disk1 is full.

Also leave the gateway on the 10GbE NIC blank.

I don't use bridge, just have a different IP range for the 10GbE NICs and then connect using those IP addresses, can also still connect by gigabit if needed using the gigabit IP.

Sorry, forgot about that, you need to update manually, download the beta zip and extract only the bz* files overwriting the exiting ones.

You can do the upgrade using the GUI: Tools -> Update OS and change the brach to "next" then check for updates, no data is lost but good to read the release notes.

That would mean a disk clearing, any data there will be deleted.

Isn't the old 3TB disk missing from the array?

Unassign parity, start/stop array, re-assign parity.