itimpi

The mkpkg command is being user with the option to force 'root' user so they should install fine and have the correct permissions, but I will check this out anyway.

Unfortunately not You could use the User Scripts plugin to periodically run a command of the form ls -R > outputfile but that could be a lot of output on a large array with possibly millions of files

I am surprised this matters as normally not that much is written to the syslog. Other things writing to the cache (e.g. docker containers) is far more likely to be writing many orders of magnitude more data to it. Writing to the ‘flash’ drive is different as that has far more limited number of write cycles.

When you later restart the array in normal mode does the ‘emulated’ drive mount OK, and if you click on the folder icon against that drive does it show the folders/files you expect to see?

Don't see how that could matter. I have not tracked down anything yet that can cause the exact symptoms you describe although I have identified an anomaly if the system is set to report temperatures in Fahrenheit, but that does not appear to apply to you.

When you used UFS Explorer did you make sure that it treated the drive as the format it was BEFORE you used it as parity? If I remember correctly that was XFS.? If you did then it sounds as if too much damage was done to allow for any recovery.

did you also delete the (hopefully now empty) appdata folder off that drive? Until you do that drives space will be included in the space calculations for the appdata share.

I am confused then - it looks as if you should not be getting those pauses Not quite sure what is happening for you but I will try and see if I can work it out. You could disable the temperature related pause/resume in the meantime to get the check to complete.

You set what is to be considered ‘hot’. You can set the warning and critical temperature thresholds for any drive (if to be different to the global setting) by clicking on it on the Main tab. the parity check tuning plugin then allows you to specify how close to the warning threshold a drive should get before a pause is initiated (assuming you have even enabled the option for temperature related pause/resume). At a guess it sounds to me as if you might have set an inappropriate value for this setting?

Not sure I understand the question? A format is used to erase the current contents of the drive. A parity resync just gets parity back into sync with the current status of the disks and has nothing to do with format. Neither approach will restore the disk1 contents. If you are lucky a file system repair on the disk1 might be able to do something but that has nothing to do with either format or parity resync.

No, while it is running memtest requires exclusive use of the machine with no OS getting in the way

Does anyone know whether Space Invader has done a video covering File System Check & Repair? If so I could add a link to it in the documentation. If not maybe it might be a potential subject for a future video?

The only CPU type supported by unRaid v6 is 64-bit Intel and compatibles. That page you mention should be changed to make that clearer.

Give some examples of the path/file names of the files that you want to move that are not moving, and what folders already exist within the "Plex Data" folder on disk1. That way it should be possible to get a better idea of both the fine detail of your current problem and what might be the best Split Level setting for your particular needs. You might find this section from the online documentation that can be accessed via the Manual link at the bottom of the unraid GUI can help clarify things?

UnRaid will not write to it as long as you do not add it to the array or a (cache) pool. It will still (however) count as a device in terms of the unRaid licence limits and I do not think you can stop,that. As to marking it as pass-through for the Unassigned Devices plugin that DOES make sense as it will stop the plugin from attempting to mount it. The fact it is never really passed through to a VM is irrelevant and it will help stopping accidents.

It is impossible to know what is the best setting for you without knowing a lot more about the paths of the files and how you want files to be distributed. Using the option you mention would definitely allow mover to get the files off the cache but it may end up splitting the contents of folders across more drives than you want. Some users like to apply constraints that tend to keep the contents of folders at a given level on the same drive and set a Dplit Level that will achieve it for their particular folder/filename naming scheme. However since you have set the Allocation Method to be “Most Free” maybe you are not concerned about that?

Yes, and as I said the Split Level setting you have on the share is prohibiting mover from trying any other drive as the target for moving the files off the cache. the comment about moving files off disk1 is only relevant if you want to free up space on that disk.

Probably b Probably because you have in effect told it to do so When trying to select a drive for where a file should be placed if there is contention between the various share settings as to what drive to use then the ‘Split Level’ setting always takes precedence. With it set to 1 as shown in your screen shot although the share itself can span multiple disks, once a folder has been created within that share all content for that folder is constrained to the disk where that folder is first created. You are probably going to need a less restrictive value for the Split Level setting? unRAId will never automatically move files between array drives so if you want some of the content currently on disk1 to be on other drives you have to take manual action to achieve this.

An ‘empty’ disk still has an amount of space used to hold the file system directory structures. The latest XFS driver releases in the newer Linux kernels have a larger overhead than older Linux releases.

that statement is not consistent with you saying you had formatted the disk and rebuilt parity! If you simply removed the disk so it is being ‘emulated’ then that would be a reason the files could still be seen. perhaps you should provide your system’s diagnostics zip file (obtained via Tools - > Diagnostics so we can see the current state of play

The files are still on the disk1, but the question is whether the actions you have taken have damaged the file system to the point where they are no longer retrievable. From your description you have already updated parity so that it agrees with what is currently on disk1 so the unRaid built in recovery options are not going to work. You are going to have to run some sort of recovery software against disk1 to see what you can get off it. My personal experience is with UFS Explorer running on Windows. It has a trial version which can be used to see what data looks like being retrievable, but to actually do a recovery you need the paid version. There may be other tools that can be suggested - I would wait to see if anyone chimes in. Whatever you do make sure that nothing further gets written to disk1 as each write would reduce the chance of successful data recovery.

They are very fancy filing cabinets You need to ask the maintainers of the Linux file system drivers that question The most recent version of XFS seems to use much more space than earlier releases because of new underlying functionality that has been added (although I do not think unRaid exploits it yet).

The basic plugin functionality to handle pause/resume of parity checks (and other array operations) and using increments works on all recent releases the features that require the 6.9.0 rc release are: restarting parity checks from the point reached that were in progress when the system is shutdown or rebooted the Partial parity checks used by the Parity Problems Assistant. These options are not available on the 6.8.3 release as they rely on some new low level functionality that is only present in the 6.9.0 rc releases. If running on 6.8.3 the GUI will highlight what options cannot be used. I had to decide between hiding such options in the GUI or leaving them visible (but disabled) with a message stating why they were disabled and went for leaving them visible. Many people now seem to think the current 6.9.0 rc2 stable to be used for their normal daily use. Hopefully 6.9.0 is not too far off leaving rc status and becoming the new stable release.

Which bit did you find confusing? That link should have told you how you could run the check and the repair from the unRaid GUI without the need to look for any other guide Feedback might allow the wording to be improved.

According to the syslog in the diagnostics you have file system level corruption on disk12. You should run a file system check/repair on the drive.