JorgeB

This is strange because it looks like only some users are seeing this, the 3 servers I've updated so far all have an AST GPU for IPMI, no monitor connected, and I don't see that error, maybe there's a way to suppress the error to avoid spamming the log, error itself looks mostly harmless.

That suggest the SSD you are using is just slower, suggest getting one known to perform better, like the Samsung 870 EVO or Crucial MX500 for example.

Enable turbo write and copy directly to the array, that will help test if it's a cache device problem.

The rebuilt disk will have the same data you see on the emulated one.

Not saying defect, I meant device related, just looks like the devices are not supported by the newer kernel, might be a device or kernel issue.

Anyone having SMB performance issues with Unraid, especially with user shares should update to v6.11.0, as mentioned in the release notes it includes Samba 4.17, and from the Samba release notes: I did some tests (see below for more details of how I do the testing) and SMB performance improved a lot when writing small files to a user share, which is where I've been noticing the biggest performance loss with each new Unraid release, I believe that the biggest part of that loss was from the Samba security related changes, without the new Samba v6.11 was on track to be again much slower than the previous release, -rc5 still uses Samba 4.16: Another thing that looks responsible for a considerable performance loss are the Spectre/meltdown mitigations, especially on later kernels, though this can vary with the hardware used, mostly CPU/board/BIOS, it's my understanding that for home users, and unless you are renting VM space, it's extremely low risk running the server with mitigation disabled, and you can do that by adding mitigations=off to syslinux.cfg, or use the existing plugin, note the performance difference with both small and large files especially with both v6.11 releases, likely because the kernel now also has mitigations for Retbleed, also note the difference in the find test, where it's just the time it takes to list 2500 files over SMB. With the new Samba release and mitigations disabled performance is a good as I've seen for many years, though v6.7 and v6.8 are still faster in some cases, likely from other Samba/kernel changes over the years, looks like any performance loss is inflated by FUSE, so what might have been a small loss turns into a much bigger one when using user shares. Tests are done using two Unraid servers running the same release for each test, small files test uses around 10K small files of various sizes that total around 10GB, large files test uses 9 large media files totaling about 40GB, each test is run 3 times by doing a timed cp command where I take the time in seconds it takes (the "runs" column) and from that the average speed is calculated, 500GB Samsung 980 NVMe devices assigned to a pool are used as the source and destination devices, find test is just how long it takes (average of 3 runs also) to list the contents from a folder with 2500 files over SMB using a disk share and a user share.

Still errors from multiple disks.

Looks more like a device problem, but you should create a bug report, and post the output from v6.9 and v6.11.

Usually you just need to bring the device back online and run a scrub, assuming there are no "nocow" shares, more info here.

That's missing a lot of info, including device brand/model/serial, typical output looks like this: DEVLINKS=/dev/disk/by-id/nvme-Samsung_SSD_970_EVO_1TB_S5H9NS0NB15476D /dev/disk/by-id/nvme-eui.0025385b01410415 DEVNAME=/dev/nvme3n1 DEVPATH=/devices/pci0000:00/0000:00:03.3/0000:07:00.0/nvme/nvme3/nvme3n1 DEVTYPE=disk DISKSEQ=20 ID_MODEL=Samsung SSD 970 EVO 1TB ID_PART_TABLE_TYPE=dos ID_SERIAL=Samsung SSD 970 EVO 1TB_S5H9NS0NB15476D ID_SERIAL_SHORT=S5H9NS0NB15476D ID_WWN=eui.0025385b01410415 MAJOR=259 MINOR=4 SUBSYSTEM=block USEC_INITIALIZED=32096967 Which brand/model are the devices?

Also

From v6.11.0 please post output of: udevadm info -q property -n /dev/nvme0n1 udevadm info -q property -n /dev/nvme1n1

Unraid doesn't support WiFi but you can get a WiFi client AP with Ethernet ports that you can then connect to the wired NIC.

You'll also need to do a new config after removing any drives so that the array will start with the remaining ones.

Please post the diagnostics.

Everything looks fine for now.

Though rebuilding is what recommended you can move the data after a disk gets disable, by moving it from the emulated disk to other array disk(s), it will be slower than normal though.

Strange one, do you have another PC you could use the flash drive with just to test if you have the same issue when changing assignemnts?

There are issues with multiple disks, could be a power/connection problem or just the controller.

Disk dropped offline so there's no valid SMART report.

https://bugzilla.kernel.org/show_bug.cgi?id=215763

This can sometimes help: https://linux.die.net/man/1/file Disk looks fine, parity check should find no errors, assuming it was in sync before, and assuming the server did a clean shutdown. Best way to protect against filesystem corruption and other issues is to have backups, but if you get multiple occurrences of unexpected filesystem corruption it might indicate a hardware issue, like bad RAM.

According to diags disk2 was never formatted, it needs to be formatted before use.

Please use the existing plugin support thread: