trurl

SMART for disk8 looks OK. I always do an extended test in this situation too, then just reset the error count if everything is OK (Main - Array Operation - Clear Stats). When was your last parity check? Did it have exactly ZERO (the only acceptable result) sync errors?

In fact, except for syslog, the other 2 of your attachments don't provide any information at all. Diagnostics includes that syslog and a lot more as mentioned, so we always prefer the complete Diagnostic ZIP file. In some cases it might be useful to get older syslogs from setting up Syslog Server, but we can see about that later. The syslog you did attach is spammed with nvidia related entries. Do you have the same problems if you use the stock Unraid? Please attach the Diagnostics ZIP file to your NEXT post in this thread.

Assuming you have no bottlenecks due to port multipliers, disks are read in parallel and it is all the same very fast calculation, so number of disks should have no impact due to these factors. Normally all HDDs are faster on the outer cylinders and slower on the inner due to data density. Same RPM but more circumference on the outer has more data per rotation than the inner lesser circumference. And, the progress goes from outer to inner so slower later on is normal. Smaller disks are slower than larger disks as a rule due to data density. So as the smaller disks are finished there may be some increased speed due to the (slower) smaller disks not being involved, but that may be offset by the fact that the larger disks remaining are further along in progressing towards the slower inner cylinders. And, of course, some disks just don't seem to perform as well for some reason. I suspect you are actually seeing the effects of the slower inner cylinders and not really the effects of the smaller disks being finished. Have you tested the speed of your individual disks using the DiskSpeed docker?

Changed Status to Open Changed Priority to Minor

Probably would have made more sense to just post in the release thread, and you haven't given much information. Have you read the entire release thread? Is the VM using vdisks or are you attempting to passthru actual disks to the VM? Downgrading to Minor

Definitely a browser issue then. Have you tried clearing browser cache?

If you have an adblocker whitelist your server.

If you have an adblocker whitelist your server.

It will rebuild the disk from parity. That is what is required because the disk is not in sync. Unraid disables a disk when a write to it fails. After a disk is disabled, Unraid does not use it again until rebuilt. Instead, it emulates the disk from the parity calculation using parity and all the other disks. Emulation includes writing. That initial failed write, and any subsequent writes to that disk, updates parity, so those writes can still be recovered by rebuilding the disk. Just assign the disk and start the array to begin rebuild.

OK. Just trying to confirm that your last parity check had errors. You must run a correcting parity check to correct those. And then run a non-correcting parity check to confirm you don't still have any. Exactly zero sync errors is the only acceptable result and until you get that result you aren't finished fixing things.

Plex and many other apps run as dockers

Emulated disk3 is mounted so rebuild should be OK. Is unassigned disk sdf serial ending 6SLT the disk that should be assigned as disk3?

Disk is unmountable but not disabled, SMART looks OK. Rebuild is not the solution to unmountable. You must repair the filesystem: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Be sure to capture the results so you can post them.

You must configure Notifications to alert you immediately by email or other agent as soon as a problem is detected. Don't let one unnoticed problem become multiple problems and data loss.

I am in favor of not autostart if a disk is disabled or missing, but see my replies on your other thread about why you must rebuild anyway.

No it is still out-of-sync. Unraid disables a disk when a write to it fails. After a disk is disabled, Unraid does not use it again until rebuilt (or new config as mentioned). Instead, it emulates the disk from the parity calculation using parity and all the other disks. Emulation includes writing. That initial failed write, and any subsequent writes to that disk, updates parity, so those writes can still be recovered by rebuilding the disk. Has absolutely nothing to do with autostart since it is already out-of-sync as soon as it is disabled. If you did New Config without rebuilding parity, then your array is out-of-sync. You must do a correcting parity check to get it back in sync. And then you should do a non-correcting parity check to verify that you have no sync errors. Exactly zero sync errors is the only acceptable result and you aren't finished fixing things until you get that result.

Rebuilding is required because the disabled disk is out-of-sync with the array. Just enabling it without rebuilding will not fix the out-of-sync. The only other possibility is to rebuild parity instead so everything is back in sync, but since it is the disabled disk that is out-of-sync it usually makes more sense to rebuild it.

unBALANCE is about disks, mover is about user shares. unBALANCE moves from specified disks in the array to other specified disks in the array. Mover moves user share files from cache to array or array to cache based entirely on the settings of each user share. Each user share's settings controls which disk the files wind up on.

That diagnostic is without the array started so can't tell anything about the emulated disk3. Start the array and post a new diagnostic.

Go into your BIOS and set SATA controller to AHCI (currently using IDE mode) and try rebuild again

Parity is not a substitute for backups, whether Unraid or any traditional RAID. All parity allows you to do is rebuild a missing disk. Other reasons for data loss are much more common than failed disks, including user error. It's not a question of disabling trim for array disks because it is not enabled. It is simply a fact that SSDs in the array cannot be trimmed.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. These words do not belong together and suggests you are considering making a VERY BIG mistake. Don't do anything without further advice.

Are you referring to the fact that parity and disk1 are disabled? They are being emulated until rebuilt. Looks like emulated disk1 is mounted so that's good, and since you have dual parity you can rebuild both. Since you rebooted nothing in syslog from when the problem occurred. No amount of messing with the hardware will re-enable a disk.

Don't understand what you mean by "without parity". Parity disk seems to be OK and not disabled. If you corrected parity errors you must run another parity check to verify. Exactly zero parity errors is the only acceptable result and if you didn't get that on your last parity check you aren't finished. See if there is anything useful for you in this thread: