itimpi

This implies that the flash drive has dropped offline (or was never mounted if this is just after booting).

It might be worth mentioning that you can have a ‘stop’ file that is similar to the ‘go’ file that is run near the end of the shutdown process. Not very well documented.

Also 5 Reallocated_Sector_Ct PO--CK 100 100 010 - 3712 197 Current_Pending_Sector -O--C- 100 100 000 - 8 198 Offline_Uncorrectable ----C- 100 100 000 - 8 are not good signs as ideally these should all be 0. As @trurl said replace

According to your diagnostics your syslog is being spammed with messages of the form: May 21 10:45:25 server kernel: sd 7:0:18:0: [sdf] tag#110 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s May 21 10:45:25 server kernel: sd 7:0:18:0: [sdf] tag#110 Sense Key : 0x5 [current] May 21 10:45:25 server kernel: sd 7:0:18:0: [sdf] tag#110 ASC=0x26 ASCQ=0x0 May 21 10:45:25 server kernel: sd 7:0:18:0: [sdf] tag#110 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00 May 21 10:45:25 server kernel: blk_update_request: critical target error, dev sdf, sector 941623360 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0 with the sector number changing. The sdf device appears to be your cache2 device. This makes it sound as if it could be failing

That gives you the choice of using the emulated disk or the physical disk going forward (or some mixture of the two).

Except for the fact that even iperf3 is only getting 10MB/s so it has nothing to do with the speed of reading/writing to the drives. Something somewhere on the network is limiting the speed. However since you mention services running on Unraid are getting 100MB/s it also does not sound like something at the Unraid end either I must admit I am puzzled because you seem to have checked all the obvious candidates without finding a culprit

If iperf3 is only giving 10MB/s then it definitely looks like a network issue. However quite what it could be is not clear from your description. In the past when this has come up it has always been due to a link running at 100 Mb/s for some reason (bad port, bad cable etc).

Great You can ignore those settings if the plugin is installed (I.e. setting them is irrelevant). The plugin pre-dates those being available and it already makes sure that correct values are stored in the parity check history. I have only been making it available via CA. It is actually hosted on github and getting the .plg file from there and installing it via the Plugins tab will probably work.

In that case you should be following this process to try and repair the file system on the emulated disk.

If disk1 is being emulated then you should be able to see it’s contents just as if it was physically present. What does the Main tab show for disk1?

That statement implies you do not understand how parity works. Parity contains no data per se - it just contains the information that will allow a sector on a failed drive to be reconstructed using the information contents of that sector from the parity drive in conjunction with the corresponding sector from ALL the other array drives.

That would normally mean you have something writing to a location in RAM. Quite why I have no idea. You are likely to get better informed feedback if you post your system’s diagnostics zip file.

That indicates there is actually no specific partition on the drive (as that would be sda1).

Files in the appdata share have permissions that are specific to each container, and there is no guarantee that these will be compatible with viewing or editing them over SMB.

it looks like disk have slightly different ways of reporting their serial numbers under 6.10.0 on your system. You should be able to: Use Tools->New Config and use the option to keep all assignments return to the Main tab and correct all drives to have their new version of the serial numbers tick the “Parity is Already Valid” checkbox start the array and with any luck everything will now come up as normal.

As far as I know Unraid only tries to read the SMART data if it thinks the drive is active (spun-up). Sounds as if the USB enclosures are not tending to correctly report the drive status when they have spun down the drive.

Interesting! I only get 1 partition showing with the blkid command on my Unraid system so somehow a difference has crept in. Be interested to see what any others experiencing this issue show as the output of the blkid on their systems or if the apparent difference is a red herring. I would guess we must be getting around the time that Limetech folk come online (being US based) so maybe they will have something useful to say

No idea, but it is something different to what I normally expect to see. Limetech may have an idea when they see the screenshot. It could be worth trying to see of you can get the drive formatted with a single partition to see if it then boots? if it does turn out to be related to having 2 partitions in some way it might explain why only some people are encountering this issue.

That screenshot shows there are two partitions on the drive sda1 and sda2. Normally there would be only one partition (sda1) and that would be the one labelled UNRAID. Not quite sure what caused you to end up with 2 partitions, but it could well be what is causing the booting problem.

What makes you ask that? If there is a EFI folder on the flash drive then it is set for UEFI boot. If instead it has a trailing tilde character then the flash is set for Legacy boot.

I would not bother as drives in good health should be able to take the load. There is also the fact that copying the data elsewhere would put just as much (if not more) load on the drives. Having said that, remember the parity is no substitute for backups - it is only about protecting you from disk failures (i.e. giving high availability). There are lots of other ways to lose data that parity will not protect you from. You should therefore always have backups of anything you cannot afford to lose. Many people do not bother to make backups of media files on the basis that even if the worse happens they could recover them even though it could be time consuming. It is up to each user to decide what trade-offs they are prepared to make for convenience v safety.

Just realised that I did not answer this bit. In this case the time to rebuild a drive is determined by the size of the drive being rebuilt (at the same 2-3TB per hour estimate as used for the parity build) so if the disks are smaller than the parity drives it does not take as long. Another way to look at it is that both processes involve writing to every sector on a drive so how quickly that can be done is the determining factor.

Yes in principle the number of data drives is not normally a major factor. However, If the extra drives on a disk controller mean its throughput capability is exceeded it slows the process down thus extending the time. In addition, very slow processors the overhead of calculating parity2 (which is a much more complex calculation than used for parity1 can also mean that the CPU becomes a limiting factor. I It is also worth noting that the process slows down as the inner tracks on drives are reached as their throughput is then lower (less sectors per track that can be read in a single disk rotation).

I assume the disk that should be disk3 is the one with WSD0QVWE as its serial? My guess would be that you disturbed its connection when adding the drives you now want as Unassigned drives. It is showing up OK in the SMART reports and it looks OK there. Does Unraid show that disk3 is currently being emulated? If so check that the emulated disk has the content you expect as the process for getting it back into the array involves rebuilding the drive with the contents that are shown as present on the emulated disk3 by stopping the array; assigning the disk as disk3; and restarting the array to rebuild the physical disk3 to match the emulated one. if the emulated disk3 does NOT show the expected content then do not rebuild but post back here for advice.

You are likely to get better informed feedback if you post your system’s diagnostics zip file.