itimpi

Yes - the system will react as if the drive is present whether reading or writing. The only caveat being that with a single parity drive the writes can not assume to be 'protected' until the rebuild process has completed so that the disk being rebuilt and parity are now fully in sync with each other.

Unfortunately it looks like disk2 was already disabled before you booted even for those diagnostics so still no information about the reason. If you want to get logs that can survive a reboot then you should enable the syslog server.

Things to consider are: Reboot in Safe mode - if that works then you probably have a plugin causing issues. You should make sure all your plugins are up-to-date so they include any fixes required for the 6.12.x releases. Under Settings->Display settings is the Page View set to tabbed or non-tabbed mode? Are you using a theme? Your description sounds like what a tabbed view might look like under some theme? 6.12.3 is the current release not sure why you only got prompted for the 6.12.2 release. You probably want to upgrade to this release ASAP as it includes some important fixes to help with avoiding unclean shutdowns.

You should update to the 6.12.3 release as it had a fix relating to shutting down the server properly. Whether this will help I am not sure but it is definitely worth doing to get a better starting point.

Mover is very slow when moving small files as there is significant overhead due to checks done before moving each file. Not sure how big the files are that mover is operating on although the syslog seems to suggest it IS still doing something.

The SMART information for that drive looks OK so the drive is probably OK. The diagnostics are after a reboot so we can not see what lead up to disk2 being disabled. If it happens again for any reason it is a good idea to take diagnostics before taking any further action. The 'disabled' state will not be cleared until the drive is rebuilt as described in this section of the online documentation. The emulated disk2 seems to be mounting properly so as long as its contents look correct you can rebuild the disk onto itself, although if you have a spare drive that is always safer in case the rebuild goes wrong for any reason.

You seem to have something writing to disk1 which will slow down the parity swap drastically. I would expect things should speed up when that stops.

Not that I know of as the flash drive has to be readable at the BIOS level for booting.

2023-07-21 update Fix: Some internal changes to try and minimise chance of race conditions New: Option to shutdown server after array operation completes now ready for use

step 1 is unnecessary instead of step 2 simply unassigned the parity drive and restart the array.

We normally recommend that for initial data load you run without a parity disk assigned as then you are only limited by the speed of the drive being written.

I already have the code implemented and am currently testing that it works as expected. It was not a lot of code as most of the building block needed were already included, just not being used to trigger the shutdown at the appropriate point. I have included a safety check/escape in that you will get a notification that a shutdown is pending near the start of the check, but as long as you unset the option before the array operation finishes then the shutdown is aborted.

Yes.

The whole idea is that writes to the cache are independent of the main array and so run at the full speed the cache can support. The (much slower) transfer of files from cache to array by mover are normally scheduled to run in the middle of the night when the server is typically idle.

The problem is that any writes to the array also require writes to the corresponding sector on the parity drive. You are thus getting constant head movement back and forth on the parity drive between the sector(s) involved in the write and the sectors being accessed by the current position of the parity check process. Since head movements are comparitively slow this leads to very significant slow downs of both processes.

I think it might also not load any packages that are in the ‘extras’ folder on the flash drive (if you have this folder at all).

If you are moving files and running a parity check at the same time they will both be significantly slowed down as you end up getting disk contention. It is far more efficient to run these operations separately.

The only difference between the levels is the number of drives supported so that sounds like a badly phrased marketing messsge.

Check the paths for you docker containers. If any of them are wrong they may not map to your current devices, and if so the location would be in RAM which would explain state being lost after a reboot.

You have left our step 1.5 where you change the setting for mover on appdata to be cache->array as you want everything for that share to end up on the array. as was mentioned step 3) needs the array set as secondary storage and mover action to be array->cache. 4. Mover will now move array->pool. Mover does not support moving files between pools, only between the array and the linked pool. step 4.5 change the settings for appdata to set secondary storage to none as all of appdata should now be on the pool. You can also set Exclusive mode for better performance. step 4.6. Check all docker/config configurations to make sure they never reference the old cache pool. Going via the ‘appdata’ share is now best as with exclusive mode you get maximum performance.

With Unraid you need to distinguish between Failed/Dead and Disabled. A drive being marked as disabled with a red 'x' simply means that a write to it has failed (and it is now out of step with parity if you have a parity drive(s) but does not necessarily mean it has failed as write failures can happen for lots of reasons, with the most common being issues with either the SATA or power cabling. Normally the diagnostics taken at the time and/or the SMART reports can give a clue as to which it is.

If you read the change log you will see that it mentions this option is added to the GUI, but is currently disabled due the supporting code not being ready. The next update will allow this option to be selected.

If you only want the performance of ZFS why are you even trying to set up primary and secondary storage. You want the ZFS pool to be primary and no secondary storage to get what you say you want.

That is not RAM - that is the % of the docker image file that is used for storing docker containers.

The other thing you should do is enable the syslog server to get logs that survive the crash/reboot to see if they show anything useful.