JorgeB

Maybe in the near future, at least there were some hints from Limetech that it's a possibility.

Not spining down won't cause any damage, on the contrary, most believe it's better for the devices to always be spun up, just not so good for noise/power.

Both, though SAS drives can't currently be spun down.

Replied on your other thread.

Perfectly fine to mix SAS and SATA.

Best bet is to use the dedicated support thread:

There are some SMART issues, run an extended test on all disks, or just those for now.

We need the diagnostics after it goes missing and before rebooting.

Please don't crosspost, continue discussion on the original thread:

From the may different models I used so far there's only one that consistently had a couple of sync errors after a power cycle, it was the old Kingston V300.

Acknowledge warnings, grab diags and screenshot of the dashboard, then reboot and more errors appear do the same, then post them all.

Please don't crosspost, continue discussion here: https://forums.unraid.net/topic/77813-plugin-linuxserverio-unraid-nvidia/?do=findComment&comment=855598

As long as RAID controllers are not used there won't be problem, RAID controllers can have custom IDs.

Before replacing try redoing it, backup current flash, recreate it using the USB tool then restore only the config folder.

Changed Status to Closed Changed Priority to Other

No, but I've been told I'm not "normal" Good, IIRC older Samba releases defaulted to "strict sync = no", newer Samba defaults to "yes" so it honors sync writes/write trough if requested, but as long as you have a UPS you should be fine without sync writes.

Likely the other NAS is not honoring the requested sync writes, try this, stop the array and go to Settings -> SMB -> SMB Extras and add: [global] strict sync = no See if it makes a difference.

With sync writes it will always be extremely slow, because the write itself is much slower than normal and you don't get the cursor back until it finishes flushing all data to the array, either sync writes can be disable or you'd need to use a different protocol like nfs (which I'm not sure it's still supported by Windows).

Changed Status to Open Changed Priority to Minor

Since it's a Revit known issue going to downgrade this for now, and I don't think LT can do anything about it, but lets see.

Did just that and can confirm I can reproduce your issue, looks to me like Revit is doing sync writes, and this appears to confirm it: https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Revit-slow-saving-to-SMB-share.html

[14:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg8 state=running queue_depth=1 scsi_level=6 type=3 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/14:0:0:0 [/sys/devices/pci0000:00/0000:00:1c.6/0000:0c:00.0/ata14/host14/target14:0:0/14:0:0:0] [22:0:0:0] process Marvell 91xx Config 1.01 - /dev/sg9 state=running queue_depth=1 scsi_level=6 type=3 device_blocked=0 timeout=30 dir: /sys/bus/scsi/devices/22:0:0:0 [/sys/devices/pci0000:00/0000:00:1c.7/0000:0d:00.0/ata22/host22/target22:0:0/22:0:0:0] In that case some of those ports are from a Marvell controller, since the SSD is currently using one.

You should try safe mode.

ATA22 (and ATA14) are Marvell related virtual devices, not actual devices, you can ignore the errors, but we don't recommend using Marvell controllers with Unraid.

Most likely, but don't remember seeing that error before, can you try again after updating to v6.8?