itimpi

Not sure where you get this idea ? In my experience SSDs are significantly more expensive than HDDs of the same capacity. At some point SSDs will probably become cost-effective so I expect that Limetech are looking at all the issues that need resolving to allow SSD’s to be safely used as array drives.

I am reasonably certain that the issue HAS been acknowledged by Limetech! We have definitely been told it is on the list of issues that are hoping to be cleared for the 6.8 rc1 release. (which is hopefully going to be made available soon). I suspect that any solution is non-trivial and is somewhere at the Linux driver level which means it can be difficult to get resolved in a way that has no side-effects elsewhere.

How many partitions are on each drive? I have a feeling that UD will only handle the first one. Also are the partition types the same?

For those who want a GUI based file manager that is hosted on Unraid then Dolphin/Krusader docker containers already provide a solution that performs better than a browser based version.

If you want a docker to use a mount point on an Unassigned Device then you should set the access mode to be one of the 'slave' variants.

if you are bypassing the Unraid GUI to install/start/stop docker containers then it is up to you to create appropriate scripts to manage this. The User Scripts plugin can help with scheduling when such scripts should run.

The problem with a web based file manager is getting decent performance. I have done some work on getting a couple of ones that look good from a functional point of view integrated into the Unraid GUI and although I have technically managed to get them working I have not managed to get acceptable performance on any array that is not relatively trivial in size. Not sure what it is that causes this performance problem but it does seem to be a consistent pattern.

I see you are running an old rc. Does this happen with a recent stable release (e.g. 6.6.6 or 6.6.7)

There is no need to have a file anywhere near that big. The default size of 1GB is probably far more than is needed as all that is stored inside it is configuration information about the VM service and any VMs you create.

The file is created when you enable VMs under Settings->VM Manager and the path to that file is also set there.

Top to bottom. You can reorder them to get a specific order. You can also set a delay after a docker has been started before the next one should be started.

Not sure there is any bug here (or if there is it is purely cosmetic) Sounds like it is a timing issue with the 1st VM still starting when you start the 2nd one and the way the GUI updates VM status. Still it does no harm to report it so that someone who understands the GUI code is aware of it in case behaviour can be improved.

UnRAID is based on Slackware so the way to do this would be to create a Slackware VM and then follow the instructions to create a statically linked version of the agent from the sources that would result in a binary that can run on Unraid. There are also some users that need to be created and these should probably be redone on each boot. Thinking about it this could be done using the User Scripts plugin with a simple script set to run on first array start rather than writing a separate plugin. I already have a Slackware VM for other reasons, so if I can find some time I might have a go at doing this myself.

I had a quick look at the documentation and it looks like support could be added without getting Limetech involved at all. It is surprising that you could not get the agent installed as a docker as that seems to be supported. However I could see it being tedious to configure as it appears you would have to pass through every disk to be monitored with its own volume mapping. However it should be relatively easy to compile a version of the agent to be installed via a plugin if the docker approach cannot be made to work sensibly. If you also wanted the server component then I assume the easiest way to do that would be as a docker container.

What needs to be built in at the kernel level for this (as Limetech would need to provide this). The remainder could then be provided as a plugin/docker so that it can be de-coupled from the core Unraid product. Doing it that way is more likely to get acceptance as it keeps to a minimum what Limetech has to actually directly deliver and support.

It is definitely worth trying eSATA as that is more likely to function reliably from a connection viewpoint than USB.

Not sure what you think is wrong? The screen shot seems to indicate that you are Clearing (NOT pre-clearing which is a different operation) the drives and until that has completed and the disks subsequently been formatted their space will not be taken into account.

The location /root IS in RAM. Whether that is a good location to store it while the server is running Is not something I can comment on since I do not use encryption.

Assum.ng you have a folder called 'isos' on the nvme drive then from the Unraid command line use a command of the form: ln -s /mnt/disks/nvmename/isos /mnt/user/isos/nvme_isos (where nvmename is what the nvme drive is called in the UD plugin) should result in what looks like a folder called 'nvme_isos' inside the 'isos' share that contains the contents of the 'isos' folder on the nvme drive and that you can get to via the GUI. I have not actually tried this but it shows what I am thinking.

Since any ISO’s are read-only after initial creation I am surprised that the performance of an array drive is not sufficient. Normally when creating a VM the iso speed is not the limiting factor. if not then a workaround might be to set up a link inside the ISO’s share that points to the nvme. That should make it show up at the GUI level I would think.

I would expect it to be a 6.8 beta or rc.

Shame If you did not then that might have explained the slowdown.

Just to check - do you have the Dynamix SSD Trim plugin (or an equivalent script of your own) to trim the SSD at regular intervals?

Add it to the 'go' file in the config folder on the flash drive.

I did not think the RC was even trying to address this problem? Instead it is focused on getting to the bottom of why some users are experiencing SQLite DB corruption. Having said that I guess the two issues could be related in some way