itimpi

what I do (and I think many others do) is XFS in the main array s it seems best from a performance/resilience perspective, and then use something like the File Integrity plugin to get checksums that can be used to detect corrupt files. Note that this just detects such corruption but does not fix it. In fact the main array does not fix bitrot type corruption regardless of the file system used. Having said that many also use BTRFS in the main array to have built-in bitrot protection as BTRFS does not seem to suffer from the same performance penalty that ZFS in the main array does. The target use case for ZFS in Unraid is really for redundant multi-device pools that can give good performance and simultaneously detect and correct any file level corruption. It is not as flexible as the main array in adding new drives but for many the performance criteria is more important. The reason for using ZFS in the main array tends to be to support ZFS snapshots from ZFS pools.

That is automatic if you specify ZFS as the format for an array drive. Note that performance of ZFS in the main array is apparently not very good if you have parity protecting the main array, so is there a specific reason you want ZFS there? Note also that not all drives in the main Unraid array have to use the same file system as parity is file system agnostic since it works at the physical sector level.

You are likely to get better informed feedback if you attach your system’s diagnostics (with everything in the one zip file) to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

ZFS drives in the array are single device pools. ÌF you want a multi-device ZFS encrypted array then it has to be done as a pool.

This can take a long time. Typically something of the order of 1-1.5 hours per TB of the drive being tested.

Strange. I do not even remember UD having a REBOOT option.

Should be no problem. Assuming the new system already has parity then that disk will be Cleared when you add it as a new data drive. After the Clear has finished you will then need to format it in Unraid to your desired file system type to get it ready to be used.

If there was a broken/cracked wire then it could depend on exactly how the cable was oriented as to whether the ends of the broken bits ended up touching. At least the symptoms matched up with the commonest cause 🙂

Looking at the diagnostics it seems that the drive that should be disk4 (a 4TB drive) is no longer being seen at the hardware level so it may have really failed. Have you checked if it is visible at the BIOS level? Have you done a server power cycle in case that is needed?

It could be the onboard NIC, but worth checking the physical LAN port on the PC end to check there is no bent pin or something similar.

What you want is not supported. However if you have no parity drive, then writing to array drives is reasonably fast anyway although limited by individual drive speed, and also you can write multiple drives in parallel without them impacting each other's speed.

you need to click on the device name (e.g. Disk1) to bring up the required dialog.

This is typical of a LAN cable where not all 4 twisted pairs make end-to-end contact. The 100Mbs speed only requires 2 of them to be operational so you can see a silent degradation from the expected 1Gps to 100Mbps. If it is not the cable itself that is faulty then it can be an issue if the socket the cable plugs into is not connecting all pins. Not sure if there is a failure mode of the LAN card/chips that can cause similar symptoms.

We know that 2) is definitely coming as Limetech have regularly mentioned this in their blogs/podcasts. Probably with the same limits of 1 or 2 parity drives per array.

You could try running the extended SMART test to see if that can complete without error (possibly after a preclear to act as a stress test and an attempt to force a reallocation of the bad sector). The short SMART test would unfortunately not be much use so anything will take some time.

This is expected as when a drive is disabled then Unraid starts emulating it using the combination of the other drives plus parity. As was mentioned we need diagnostics to give any sort of informed feedback.

Many people have no trouble at all with BTRFS. It think it is just that it is more sensitive than other file systems to underlying hardware errors, in particular dodgy RAM.

It has actually come up a number of times. I think at one time the case did not matter but it does nowadays. The flash drive is FAT32 so cannot actually store .cfg files that have the same spelling but different capitalization. If you look in the diagnostics in the /shares/shareDisks.txt file you will see an anonymised list of potential shares. If you see ones that has both an uppercase and a lower case first letter, the same last letter and the same name length then this might be the issue.

You might want to check that the capitalisation of the .cfg files for each share on the flash drive in the config/shares folder matches that of the actual share folders on the drives.

Also you are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread so we can see if the network is initialising correctly. It is always a good idea to do this to allow us to see the current state of your system and so we can see logs.

With the settings you have the syslog server is only ‘listening’ for messages from other machines. If you want the server to log to itself you need to put the server’s IP into the Remote Syslog Server field.

Did you make sure that the Docker and VM services were disabled in Settings before running mover to transfer files back? If not they will keep files open and that stops them being transferred by mover. In particular this is relevant to the ‘system’ share.

@comet424 The ‘mdcmd’ command that is in Unraid is a custom version and not the standard Linux variant so you cannot assume it works like it would on other Linux systems.

That has always been there. Perhaps you reduced the count at some point in the past to ‘tidy’ things so that unused slots were not showing when the array is stopped.

Have you tried the Manual upgrade process as that should always work Details are covered in this section of the online documentation