itimpi

I am confused. In you list of steps it was assigned in the second last step and then formatted in the last one. Why are you trying to do anything after that?

Are you sure it was not previously $59?

According to your diagnostics the check is doing exactly what you set it to do. Start at 4:00 am and pause at 8:00am until the next day! I think you settings are wrong for when it should be started as you do not want to start it again every day during the first week. You might want to consider using the Parity Check Tuning plugin to give you even more control over the checks.

As mentioned Dynamix File Manager would be the recommended tools for this.

Yes. That will not touch any existing contents but will stop new files going to the share. Are you sure you no longer want the contents on your server at all? Just checking as asking how to delete files from a share is unusual - we more often get asked how to recover them🙂 If that is the case then you can use Dynamix File Manager to do this.

Secondary can never be anything but array. You can make the array the primary and have no secondary. Yu only need both primary and secondary set if you want mover to do something, and then you can specify the direction of moves. What are you currently trying to achieve?

When using New Config I nearly always recommend using the option to keep all assignments so serial numbers do not need re-entering. You can then make changes (if any are required) from that position. Minimises the chance of error.

Not sure this is going to arrive before 7.0 (the major release after 6.13) which is now meant to be the one that treats the main Unraid array like another pool type, but I would like to be proved wrong.

Yes.

There is no setting at the Unraid level to support IOMMU - Unraid merely queries the BIOS to see if it is. If you are sure your hardware supports it then there must be a BIOS level setting required to get it made visible to Unraid.

If it was only the emulated drive that was formatted the physical drive may still have all its data intact. Diagnostics so we can check the current state of things is probably what is needed now.

Contact support with the detail and they should be able to do a manual transfer for you.

If you install the Parity Check Tuning plugin then even if you do not use its other features the parity history entries will be enhanced to tell you whether a parity check was correcting or not (and how it was initiated). If the plugin is installed then any messages from it about duration should also be correct. I think the standard Unraid release sometimes gets confused between the last check run and the one before that. I expect this to be fixed in a forthcoming release.

You will need to contact support as issues dealing with licencing cannot be handled in the forum. When you try to contact them you should get an automatic email acknowledging this. I it does not arrive you need to try again via the contact form as it means the original request did not get through.

This will be disk5. Any time you see a 'md' type device name the number refers to the disk with the corresponding number in the Unraid GUI.

You are getting a small number of retries on ata1 and ata4 in the syslog but I would not have thought they were enough to have much impact on the speed. Others have found that this frequently means that you have other disk activity going on at the same time to array drives which is badly impacting the speed. If you provided your system diagnostics we could determine if this is the case.

It is a standard Linux file system so will be readable on any system that can handle a BTRFS file system. The container binaries and working data are stored wherever you tell Unraid to store them (the 'system' and 'appdata' shares being the default locations. It is normally recommended that these are sore on a pool for performance reasons. The USB drive also stores templates for docker containers you install via the Unraid Apps tab in case you need to edit their settings or reinstall the containers with their previous settings intact. Definitely. The USB stick stores all you Unraid specific settings in its 'config' folder and this would be required if you ever need to transfer to a new USB stick. You want a backup made any time you make a significant configuration change. There are currently 3 standard ways available: By clicking on the Boot device on the Main tab and selecting the option to make a backup (which is then downloaded as a ZIP file). By using Unraid Connect to have automated backups made in the cloud on the Limetech servers. By using the "Backup/Restore Appdata" plugin which has an option to make a backup to a location of your choice when it runs to backup docker containers working data.

Issues around licencing cannot be handled in the forum, for them you need to contact support.

No. The disks will be Cleared so that parity is unaffected.

If using SATA->SATA power splitters then you do not want to split a SATA connection more than 2 way as the host end is limited by the current carrying capacity of its SATA connector. If using Molex->SATA then you can get away with a 4-way split.

Not sure. In principle you want the fastest drive as parity. Suspect this would mean one of the SAS drives but you would need to check their specs to be sure.

Not sure it would make any difference. When building parity all the data drives are read in parallel so the time is almost completely determined by the size of the parity drive - not by the number of data drives.

When you tried ZFS was that in the array or a pool? ZFS in the main array is know to be slow - it needs to be in a pool to get any decent performance from it.

That would be the normal default way to handle such a combination of drives.

UnraId emulates a drive using the combination of the other drives plus parity. In effect all writes intended for the emulated drive make the same update to the parity drive that would have been made if the physical drive was still there. Your data will be OK as long as you do not get another drive failing so that you have more failed drives then you have parity drives. In such a case you could potentially lose all the data on the failed drives. Are you sure the disabled drive has actually failed? More often than not the reason a drive is disabled (because a write failed) it is nothing to do with the drive itself but is caused by cabling or power issues. Running the extended SMART test on a disabled drive is a good way to determine if it has really failed.