itimpi

Would the approach mentioned in this forum thread achieve what you want?

This has to be related to one or more of your dockers writing something internal to the docker image. I would suggest that the way forward is to start by disabling all the docker containers and then try enabling them one at a time until you can find the culprit. Someone else mentioned that the write load seemed to be MUCH higher if the docker image was located on an encrypted drive. Is this the case for you? I do not use encrypted drives myself so I have no direct evidence if encryption does have this effect.

64GB is a very small size for a cache drive. Plex can be quite demanding on space so I can easily see you filling that up.

You can always have drives that are not part of the array mounted via the Unassigned Devices plugin. Most common file system formats are supported by this plugin. Note however that all such drives count towards the Unraid 'attached devices' license limit if they are plugged in when starting the array.

That sounds very slow for a SSD. I would expect it to be more like 560 MB/s.

You disable/enable the docker service via Settings >> Docker. You need it disabled while you delete the docker.img file, and then re-enable it to restart the docker service and get the new docker.img file created.

Not quite. If you go to the Apps tab then there is a Previous Apps option available in the Menu on the left. Selecting this will use the templates stored on your flash drive to restore your settings for each container and then download the binaries for each container into the docker.img file.

Using the Apps->Previous Apps option on a new docker image will put back the containers with all settings intact.

Normally when quoting speeds it is conventional to use a capital 'B' when you mean bytes and a lower case 'b' when you mean bits. That helps with deciding what units one is talking about.

Looking at the syslog it appears your system is failing to mount the docker.img file because it is corrupt ! No obvious reason why though. Your best way forward would be to stop the docker service; delete the current docker.img file; restart the docker service to get a new docker.img file created; and restore your docker apps via Apps >> Previous apps to get back up and running with settings intact.

If you have had an unclean shutdown then it is normal to expect a few parity sync errors as the system would have not been able to complete housekeeping and tidily unmount the drives. Typically such errors occur near the start of the parity sync process.

I had a similar problem at one point, and it turned out to be an issue with the network card at the client end sometimes resetting itself under load. having said that is could be a good idea to post your system diagnostics zip file (obtained via Tools >> Diagnostics) covering a period when you have had this error to see if anyone can spot an issue at the Unraid end.

I would think most plugins should install without an array defined, although not sure why you would want to install plugins without an array? Whether they then work as expected depends on whether they need access to the array.

That warning is a lot more scary than what occurs in practise. Running with the -L option virtually never loses any data and even if it does it only affects the last file(s) being written.

FYI: The link to their forum is under the Help menu item on the site.

Since this sounds like a generic issue with MyMediaForAlexa or an issue within Alexa itself and is not UnRAID specific it might be worth asking the MyMedia support people directly about this. You could also try the MyMedia forums on their site. I cannot comment myself as I do not have a system set up in that manner. if you get a response from MyMedia support it would be of interest to hear what it is

All important data should be backed up elsewhere. You should never trust a single system to never lose such data.

If the Export value is set to No then the permissions field should not even be relevant. It sounds like there might be a bug in that you even can change the permissions field with it in that state.

From the syslog it looks as though the disk dropped offline just before starting to generate all the read errors. That would also explain why you could not get the SMART information.

No you got it right - files can only exist in one place. For apps where performance matters the normal solution is to have the files reside on the cache and then have something in place to make backups to the array. The CA backup plugin helps with this.

Just checked - and I am also seeing that. I also see that on the Docker and VM tabs.

There is a known issue in the 6.7.2 release where writes to the array can ‘starve’ reads leading to this sort of performance issue. It is believed that this issue is resolved in the current 6.8 rc5 release although that is still undergoing validation for other issues.

Once Unraid disables a drive it stops using the physical drive and only uses the ‘emulated’ version. The advantage of this to the end-user is that they can continue to use the array as if the drive was still present (albeit with a loss of protection against further failures). If you issue a format at this stage then is assumed that it is the ‘emulated’ drive showing in the GUI that is to be formatted. If you now replace the physical drive then it is the contents of the ‘emulated’ drive that is rebuilt onto the physical drive. Since a rebuild rewrites every sector on a drive it is irrelevant if that drive was formatted before the start of the rebuild. I therefore cannot see any obvious reason why you would want to format the disabled physical drive unless you intend to RMA it and in such a case there are better ways to erase data than a format. One side-effect of this behavior is that the physical drive is left in the state it was at the point UnRAID disabled it. If you rebuild the ‘emulated’ drive onto a new disk you still have the original physical drive intact. If you now mount that original drive outside the array you can frequently access most of its content which can be useful in a data recovery scenario.

I believe this is probably an instance of a long standing issue where once you have made any edits in XML mode then you can no longer edit that VM in form mode without potentially losing the edits made in XML mode. I have wondered why a pop-up warning to this effect is not displayed when you try to switch back to form mode from xml mode. This is slightly aggravated by the fact that the toggle for xml mode is a global one and not specific to a VM. If the underlying problem cannot be easily fixed then it would be useful if the system remembered the last edit mode used for a specific VM so that at least if you go into Edit mode then if you used XML mode you are taken straight there.

The ones that are particularly worrying are: 5 Reallocated_Sector_Ct PO--CK 045 045 010 - 20272 (0 3) 197 Current_Pending_Sector -O--C- 100 100 000 - 24 198 Offline_Uncorrectable ----C- 100 100 000 - 24 On a new disk I would expect those to all be 0. If you click on the Orange icon then you are given a menu. If you select Attributes then you can see which ones have caused the status to be flagged. CRC errors are connection issues rather than disk issues and a occasional occurrence is normally OK. There is also an Acknowledge menu entry and if you select this then the icon turns green until a SMART attribute being monitored changes value.