JorgeB

Port layout, ports on h200 are vertical, on h310 are horizontal.

SMART attributes look fine but the errors are reported as an actual disk problem, run an extended SMART test, they can sometimes be intermittent or not even a disk problem.

Disk2 looks to be correctly mounted, but it didn't continue to mount the other disks, since you're on a very old release upgrade to latest Unraid, try booting again in normal or safe mode, and if still issues pleas post the complete diagnostics: Tools -> Diagnostics.

Try booting in safe mode or after unsitalling the docker folder plugin.

If you do the above it should mount correctly.

Yes, that and that it didn't mount, it should be OK then, do this: Stop the array, if Docker/VM services are using the cache pool disable them, unassign all cache devices, start array to make Unraid "forget" current cache config, stop array, reassign all cache devices (there can't be an "All existing data on this device will be OVERWRITTEN when array is Started" warning for any cache device), re-enable Docker/VMs if needed, start array. P.S. stopping docker/VMs won't matter since array was already started without a pool, but since I copy/paste the reply it's complete.

If not, do you remember if the cache mounted? Is the pool raid1?

That might be a problem, do you have those diags?

Did you start the array with a single cache device assigned?

Disk dropped right after spin down: Jul 22 14:34:43 HurtadoServer kernel: mdcmd (45): spindown 5 Jul 22 14:35:58 HurtadoServer kernel: sd 12:0:3:0: device_block, handle(0x000b) Jul 22 14:36:00 HurtadoServer kernel: sd 12:0:3:0: device_unblock and setting to running, handle(0x000b) Jul 22 14:36:00 HurtadoServer kernel: sd 12:0:3:0: [sdi] Synchronizing SCSI cache Jul 22 14:36:00 HurtadoServer kernel: sd 12:0:3:0: [sdi] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 Jul 22 14:36:00 HurtadoServer kernel: mpt2sas_cm0: removing handle(0x000b), sas_addr(0x4433221105000000) Jul 22 14:36:00 HurtadoServer kernel: mpt2sas_cm0: enclosure logical id(0x51866da06d30c200), slot(6) Set spin down to never on that drive and see if it makes a difference.

Changed Status to Open

I'm still having pool spin down issues on one of my servers, can't figure out what the problem is, shouldn't be controller related as they are on the Intel SATA ports, but can't reproduce the problem on my test server. No disks from any pool spin down, most of the pools are used once daily, if I spin them down manually they spin down and stay spun down until the pool is accessed, but after a few seconds or minutes the status changes to active and the temps are not correct, first it's all sequential numbers, then it displays the same temp as my cache device, generating disk overheating notifications for all disks, but during this the disks remain spun down, once they spin up temps start showing correct but they will also remain spun up unless manually spun down, any ideas? tower1-diagnostics-20200728-1441.zip

You'll likely need to do something like this:

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.

Just enter the old key.

Don't know, never used it.

Changed Status to Closed Changed Priority to Other

No problem, for the future please note that before making a bug report you should test in safe mode:

Do you have the docker folder plugin installed?

Unfortunately you can't, unless you have this configured.

I'm saying that some SSDs suffer from bad performance when not 1MiB aligned, especially when used on a pool. Turbo write only maters when writing to the array, though it will mater when moving the data from cache to the array. Not sure what you mean, if you mean the small HDD RAM cache it will already be used, unless it's disable on the device.

You can, and it should be done on the general support forum.

or are using the most free allocation setting, which will keep changing disks making writes overlap for a few seconds.

I use turbo write for all my serves and I can transfer for hours continuously using it, except for a few seconds when it changes the disk it's writing to, if for you it's changing to rmw mode constantly you have something else accessing the disks, e.g dockers, etc.

Yes. Because it also shows the total number of seeks.