JorgeB

Currently there's no good driver support for your NIC, it should be included with next beta release (v6.9-beta23) which is expected very soon.

Yep, you need to.

Please post new diags with the array started.

Not limited if you use the LSI IT firmware.

Best bet it to use one of the existing Wiregueard support/config threads.

There are known issues with Realtek and Linux in general, some NICs work reasonably well, others not so much, and it can change with any new release, if you can use Intel NICs.

That NIC should work with the next beta.

Go to Broadcom's support site, it's under legacy.

This isn't a really recommended way of using Unraid, you can do it, but at least make sure you have a way of monitoring the RAID and individual disks health, i.e. make sure you're warned if there's a problem with the RAID or it might be too late when you notice. The cache pool can be used as direct storage, it just dependents on how you configure the use cache setting for your shares, also with 4 devices I would use btrfs RAID10 (or RAID5 if you have good backups).

https://forums.unraid.net/topic/93941-cant-connect-to-network-on-new-unraid-build-maybe-ethernet-driver-issue/?do=findComment&comment=870517

Procedure looks to be all correctly done, and honestly I could never imagine how it could be user error since any deviation from the procedure will abort it or not even work, the sync errors start right after the 8TB mark, and curiously they are not on every block, it's every third one, I'm going to try and duplicate this with similar size disks to see if I can find out what's triggering it, if I can't I'll ask Tom to take a look.

Run without -n or nothing will be done, and if it asks for it use -L

You can find the 9211-8i firmware on broadcom's support site, under legacy.

I can't really understand what happened, and why the pool recovered after a format attempt, I can see wiping a device failed because it was busy, that's likely part of what helped, still most likely you were just lucky, that should never happen.

That's normal with btrsf, it's the the allocated size, btrfs first creates empty data and metadata chunks before writing data there, so there are 90GiB of chunks on disk and 86GiB are used. raid1, so 86GiB x 2 Because the GUI uses GB, not GiB, 86Gib=93GB

You can still swap them with another disk.

Enterprise devices should still maintain good performance even without trim.

It should be mostly dependent on the SSDs used, like mentioned I also haven't noticed any slow on my SSD array so far, I'm using WD Blue 3D SSDs for data and a WD Black NVMe device for parity, what are you using?

SMART attributes look OK but there's a recent device error logged, difficult to say if it's a disk problem just by that, I would suggest replacing/swapping cables on that disk to rule them out and rebuild, if it happens again after that it's likely a disk problem. P.S. also a good idea to update the LSI firmware since it's very old, current release is 20.00.07.00

Probably best, since there are much less Mac users here, more likely to you get their attention that way.

Yep.

Try booting in UEFI mode, you need to enable it when creating the boot device, or go to the flash drive and rename EFI- to EFI.

File system corruption is usually not a device problem, though it can be, posting the diags might give some clues.

It's a very important thing to keep in mind with flash devices, cheaper devices can't sustain high speeds for long, usually also depends on how full they are, here's an example from my test server with a cheap TLC SSD, started with the SSD like new after a full device trim: After 30% rebuilding: And is stays like that until the end, good SSDs like the 860 EVO, MX500, etc, can sustain good writes speeds always, large capacity models are also usually faster at writing than small capacity models, since they can write in parallel to the various NAND chips:

Please post the diagnostics: Tools -> Diagnostics