JorgeB

Disk is formatted with type 2 protection, you'll need to remove that.

You can also try a different NIC driver, new default one (virtio-net) apparently doesn't perform as well as for example virtio, but it still shouldn't do that.

Maybe you could use total-free to calculate used, in this case it would be about 240MB which is different than df reports but sounds about write for an empty fs, if you think that's a possibility I could run some test to see if it always reports the correct space for various profiles and usage scenarios, alternately, btrfs-progs 5.7 can finally report the correct stats from raid5/6 profiles with "btrfs fi usage", so maybe easier to get it from there once btrfs-progs are updated.

root@Test:~# stat -f /mnt/cache File: "/mnt/cache" ID: 98929008f93c43e2 Namelen: 255 Type: btrfs Block size: 4096 Fundamental block size: 4096 Blocks: Total: 31266616 Free: 31207938 Available: 22859018 Inodes: Total: 0 Free: 0

First thing to do would be to respect the max supported RAM speeds depending on the config, you're currently overclocking the RAM, also check the power supply idle control setting.

I believe it's not currently possible, at least no with the GUI, maybe manually, but it doesn't affect the shares, since those will remain the same, you'll need to correct any internal paths though. "/mnt/pool/share" is shared as "\\tower\share" if you e.g. change the pool name "/mnt/new_pool_name/share" is still shared as "\\tower\share"

It's normal, parity doesn't have a filesystem, so no utilization.

loop3 is the libvirt.img, and you're getting errors because it currently resides on disk1 and disk1 is full, you can set the system share to cache=prefer and then use the mover to move it to the cache device, VM service needs to be disable first, also disable docker service if in use.

No, parity check reads the entire disk surface, so if there are errors they're bound to show up during it.

Tools -> System Devices

It was released today.

There are some strange errors that might be part of the reason it's not being detect by Linux, like these: Jul 7 19:54:01 otfgserver kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window] Jul 7 19:54:01 otfgserver kernel: caller _nv000908rm+0x1bf/0x1f0 [nvidia] mapping multiple BARs Jul 7 19:54:03 otfgserver kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window] Jul 7 19:54:03 otfgserver kernel: caller _nv000908rm+0x1bf/0x1f0 [nvidia] mapping multiple BARs Jul 7 19:54:06 otfgserver kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window] You can try another slot, look for a bios update, etc, but this is still true:

Until the NIC is detected, i.e., it shows up on the devices list (or lspci) having the driver or not won't make any difference.

This appears to be fixed but the used space is now wrong, maybe there's another way to get it, like whatever df uses, this is an empty raid5 pool with 4 x 32GB devices, free space now correctly accounts for parity unlike before, but note the used space:

Since it's a very old release you need to do a manual update, 6.5.3 was deleted from the cloud some time ago.

emhttpd segfaulting is likely an Unraid issue, Tom might be able to know the reason by the error but if you can get the diags best to add them.

Yep, no issues.

Hmm: Jul 8 09:38:54 Test emhttpd: writing MBR on disk (sdd) with partition 1 offset 64, erased: 0 fdisk -l /dev/sdd Disk /dev/sdd: 111.81 GiB, 120034123776 bytes, 234441648 sectors Disk model: TS120GSSD220S Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdd1 64 234441647 234441584 111.8G 83 Linux root@Test:~# cat /sys/block/sdd/queue/rotational 0

Syslog posted is empty, so we can't see what happened, reboot, start the array and post new diags.

It does look like a genuine problem, both these attributes should be 0 on a healthy WD drive: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 68 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 24 But these error can be intermittent, also confirmed by the SMART test passing, but likely there will be more errors in the near future, together with those attributes increasing, if they remain stable disk still might be good for some time.

It's not being detected by Linux, so there might be a driver, if you can get it detected, it will never work if it's not, and this is not a software problem.

Best bet is to use the existing plugin support thread:

Tools -> Diagnostics

btrfs is not really standard RAID. You can add (and remove) disks at any time, you can even uses different size disks. But note that btrfs raid5/6 is not yest considered safe for production use, it can be used, I have several raid5 pools, but I only recommend them for anyone with stable hardware and good backups.

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.