itimpi

Yes - you should get the behaviour you want. In this case the check should finish during the second increment if there are no problems. With bigger drives you would get more increments as the total execution time increases.

Fair enough - I assumed that you had from your mention of enabling using Turbo Write, which is not relevant without a parity drive. It might be worth posting your system diagnostics zip file (obtained via Tools >> Diagnostics to see if those might suggest a reason.

You never get this speed in Unraid writing to a parity protected array drive as each logical 'Write' operation in Unraid is multiple steps: Read the target sector from the target drive and the parity drive(s) (in parallel). Calculate the new contents of the parity drive sector(s) from the change to the target drive sector Wait for the target drive and parity drive(s) to complete a disk revolution. Write the new sector contents to the target drive and the parity drive(s) (in parallel). In this mode speed is limited by the fact one always has to wait for a disk revolution as part of the logical 'Write' operation. The big advantage is that there is no need for other drives to be spun up for this operation to succeed. If 'Turbo Write' mode is enabled then the algorithm is closer so that used in a parity check: Read the target sector from all data drives EXCEPT the target drive (in parallel). Calculate the contents of the target sector on the parity drive(s) using the data from the array drives and the new contents of the target drive. Write the target sector to the parity drive(s). The idea is to try and improve speed by eliminating the need to always wait for a full disk revolution as part of the 'write' operation. However the speed in this mode will never exceed the speed that can be obtained in a parity check. The big disadvantage of this mode is that it require all array drives to be spun for this operation to complete.

It has never been necessary to make this assumption at the user level as once you have done the pre- clear then Unraid will simply accept any new drive as ready to go without affecting parity as it can tell from the pre-clear signature being present that parity remains valid.

Yes - this is no problem at all.

I am surprised that your system cannot run VMs if it is 64-bit capable. What many systems do not support is hardware pass-through, but this is not a prerequisite if you do not need graphics performance.

You are getting continual resets on disk4 which is why things are going slow. It is probably a cable connection.

That normally means you have a browser session open somewhere from before the last reboot of the Unraid server.

I would suggest putting the flash drive into a PC/Mac and sunning a check on it. The symptoms suggest that the system has not managed to read the 'paid for' licence file so there may well be some corruption. If your backup is recent then an option is to reformat the flash drive and then put the backup onto it. Does the backup have the correct licence file for this flash drive? You probably also want to remove the trial key file to avoid any confusion.

It is worth pointing out that each Unraid array drive is a self-contained file system that can easily be read on any Linux system (or other systems if they have the appropriate file system drivers installed).

Stop file is definitely run after the array has been shut down, but I am not sure about other system services that are not dependent on the array. I will have to add a log message to mine to see exactly when it is run.

This is probably due to disk activity from docker containers. What containers are you running?

Not sure that has ever existed! /dev/disk (without an ‘s’) does exist. Perhaps you are thinking of /mnt/disks as is used by the Unassigned Devices plug-in?

Yes - you can grow the array dynamically. Although Unraid will support them it is recommended that avoid using USB drives in the main array. the reason is that Unraid is not hot-swap compatible and cannot handle array drives temporarily disconnecting and then re-connecting with a different device ID (as USB drives are prone to do).

The top two are ones that are normally set to Use Cache = Prefer (or Only) so if all files for that share are only on the cache the free space will reflect what is free on the cache drive. The fact that the system share is showing 6TB despite it being set to Prefer means that there are files belonging to that share on the main array as well.

The syslog shows that you are getting all sorts of I/O errors on what I presume is your cache drive. Quite why I am not sure - it looks like it might be hardware related so you probably want to check all the connections to the drive. If that checks out OK then running a file system check on the cache drive is probably the thing to do BTW: It is always best (and easiest) to post the system diagnostics zip file (obtained via Tools->Diagnostics) as this provides more information to those trying to help.

have You checked under Settings->Global Share settings if you have restricted which disks can be used for shares? also what about the settings for individual shares.? If you post your system diagnostics zip file (obtained via Tools->Diagnostics) you might more informed feedback as we could then see how you have things configured and what is happening on your server.

It is probably a good idea to read the help built into the GUI for the meaning of the Use Cache setting. This is one that new users frequently get wrong.

UnRAID never automatically moves files once they are on array drives. The only time files are moved automatically is in the special case of to/from the cache dependant on the value of the Use Cache setting for a share. you might want to look at the Split Level settings for your shares. In the event of contention between the Allocation Method and Split Level settings then the Split Level always wins. This can force files to go to disks that already quite full. in terms of moving files that are already on the array, you might want to look into using the unBalance plugin.

The main thing is to go for a brand name USB2 drive rather than a USB3 one as they seem to be more reliable and you get negligible performance benefit in Unraid from using USB3. Heat also seems to be a factor in the likelihood of failure so some people also recommend avoiding the small form factor variants as they more prone to heat related issues although personally I have used Sandisk Cruzer Fit without issues.

CRC errors are nearly always related to the quality of the cabling, and are rarely a problem with the drive itself. Also CRC errors never get reset so if they are not increasing there is little cause for concern.

It does reset the array so that you can assign drives as you want them (which is why it invalidates the current parity). However Unraid will recognize a drive that has previously been partitioned by Unraid and will leave its contents intact when assigning drives to the array.

Speeds of 30-40MBps are typical for writing to the array. Each ‘write’ operation actually involves a sector read from target and parity drives; a disk revolution; and then a sector write to the target and parity drives. With small files the speed tends to be lower due to the overhead of creating the relevant directory entries. Enabling ‘Turbo’ mode can speed up things as it eliminates the initial read from target/parity drives but at the expense of needing all drives spun up.

Any folder name that appears after the /mnt/user0 part becomes a User Share of that name. Just make sure the name is what you want the User Share to be called (and it should NOT be of the form 'diskX').

Regarding point 2, this is valid but it will end up creating User Shares of ‘disk_name’ which is going to confuse the system if those are of the form disk1, disk2, etc as those normally refer to physical drives, not User Shares.