testdasi

🥱

Install User Scripts plugin from the app store Settings -> User Scripts -> create a new script -> copy paste script to the edit box -> save -> on the schedule box choose at first array start

Read post from 1812 on page 9 (quote below) for the script to run at startup. Then point the container path to /tmp/PlexRamScratch The script restricts the size of /tmp/PlexRamScratch to 4GB so you Plex does not use all the RAM. 4G is a good starting point but you can adjust depending on needs.

From the console, run "mc" to launch Midnight Commander then navigate to /mnt/user/[share name] to delete files then go to the GUI to delete share (which should now be possible as the share is empty). For a more Explorer-like interface, you can use Dolphin or Krusader dockers. The path to delete will be different depending on how you do the docker mappings. The reason to delete from the GUI is to also delete any redundant smb settings.

I assume "DSM" and "SHR" is Disk Station Manager and Synology Hybrid RAID. In which case, I don't think there's any straight-forward ways to mount the SHR volume on Unraid directly. Xpenology supports btrfs so if I were you, I would boot Unraid, change default filesystem to btrfs (in Settings) then create an array out of 2x 3TB (no parity for now) and format them. Then boot back to Xpenology, create single volumes (i.e. no RAID / JBOD) out of EACH individual 2x 3TB (assuming there's no funky thing behind the scene preventing using btrfs here) and then do the copy from Xpenology to these individual 3TB volumes. Make sure you verify that the copy is done correctly. Then boot back to Unraid, you should now have array with data. Reverify the data! None of the steps are data destructive (even the format is done on the 2x 3TB which you mentioned are unused, thus no data to destroy) so your data should be safe. I would do and redo data verification very carefully though before permanently switch.

What is your SSD in the cache pool? Generally a good idea to attach your diagnostics as well (Tools -> Diagnostics -> attach full zip file). It's not uncommon for a failing drive and/or slow drive in cache causing everything to grind to a halt (since docker and VM need IO from cache). The high CPU usage is a red herring in a sense because it's not really CPU usage but rather high IO wait (think of it like your CPU core freezes while waiting for the storage device to respond). The dirty ratio tweaks and memory parameter are just ways to reduce IO and/or make IO less random and more sequential. However, they are like putting a bandage over COVID-19 if you have a more fundamental problem with your cache drive(s). Docker -c is the same as --cpu-shares which limit the share of CPU processing power when there are multiple competing processes. I highly doubt it would have any impact on your situation since high IO wait isn't processing share. In fact, the reddit you quoted -c=1024 is rather pointless since the default value, if not provided, is 1024.

Hyper-V does contain a workaround to fix error code 43 with Nvidia GPU so if you need that for your VM to work then indirectly you need Hyper-V. There are also some other tuning for AMD Threadripper that are in Hyper-V but they are good-to-have and certainly not necessary. Otherwise, you can safely turn off Hyper-V on the host. In the guest (is that what you mean by "inside the Windows VM"?), you shouldn't turn on Hyper-V. It may prevent your VM from booting - it has happened to me. Hyper-V is also disabled by default when you install Windows. It is certainly not needed since it's used for virtualisation, which would constitute nested virtualisation, which is usually not needed since you have KVM/qemu from Unraid.

Then there isn't much more you can do. A quick google seems to suggest Tekno Parrot goes out of its way to prevent being run in a VM.

Try adding this above </features> to see if it helps. <kvm> <hidden state='on'/> </kvm> It depends on how your app detects the VM status so YMMV.

Picking host passthrough shouldn't prevent you from running multiple VM on the same cores. Perhaps you are confusing that with PCIe passthrough?

I would suggest you create your own topic instead of digging up something from 2017. Remember to copy-paste the xml of your VM and the list of scsi devices AS TEXT i.e. no screenshot. Please use the forum code functionality (the </> button next to the smiley button) so the text is formatted correctly. IOMMU is required only for PCIe pass through as far as I know. This isn't PCIe pass-through so hopefully it would be ok.

It depends. Try to keep the script simple first. AFAIK the P2000 doesn't have reset issues but then I don't think there are many people sending server to sleep like yours.

You can't. That pegged core is feeding data to the GPU. You can add --cpu-shares=64 to the fah docker extra parameters box (advanced view) and pin a single core to the docker. That way the core would still run at 100% but when there are other dockers needing the power, those dockers will be prioritised over fah. If you have important VM that needs to run then you isolate those VM cores and not let fah use it.

Try this (here I'm assuming your Plex docker is named "Plex") #!/bin/bash docker stop Plex sleep 5s echo "disconnecting amd graphics" echo "1" | tee -a /sys/bus/pci/devices/0000\:03\:00.0/remove echo "disconnecting amd sound counterpart" echo "1" | tee -a /sys/bus/pci/devices/0000\:03\:00.1/remove echo "entered suspended state press power button to continue" echo -n mem > /sys/power/state echo "reconnecting amd gpu and sound counterpart" echo "1" | tee -a /sys/bus/pci/rescan echo "AMD graphics card sucessfully reset" docker start Plex What it does is it stops the Plex docker, wait 5s (for it to stop completely) then does whatever it does in your script and once fully back up, it start the Plex docker. That way hopefully the docker isn't "aware" of the standby and hopefully pick up the P2000 right backup. Obviously if your P2000 itself hasn't woken up from the sleep then it's a different matter.

I could have explained it clearer. The rclone upload job could be terminated silently (e.g. out of memory is the most frequent problem I have seen), in which case, the termination of upload script due to existing ongoing upload is actually an indication that something is amiss. This would be missed by the users if the script is run on a regular schedule during the initial massive upload. Most users don't check the upload log (and network stat etc) and just assume things are just going in the background.

Then the "error" is expected. One of the upload is still running (as Kaizac said, 12Mbps is rather slow) so naturally the next run would stop. The whole upload control file is exactly for this scenario i.e. avoid running multiple uploads of the same file to the same source. You shouldn't be running the upload script on an hourly schedule with such a slow connection to be honest. At least don't run it on schedule untill everything has been uploaded.

What are you trying to upload? Has your prior run managed to finish its upload before you start the 2nd one?

To both: if you have waited more than 8 hours and still no work, restarting the docker / app (if you use windows) may help. The server is indeed overwhelmed by the public responses, complicating the matter with a bug that can cause f@h to be stuck in a loop if it receives http error. Obviously, don't restart the docker all the time because you will worsen the matter by giving extra unnecessary load to the already overwhelmed servers. And of course, it's even better if you can run both BOINC and f@h at the same time. I recommend 2 BOINC projects: Rosetta and World Community Grid. Between the 2 of them, you should have plenty of work to do (not necessarily everything contributing to COVID-19 but certainly to other good medical causes). Rosetta has already participated in the COVID-19 research (and released news article of their contribution).. WCG has also released a statement that they are reviewing COVID-19 related projects to add.

227802

We seem to have a pretty strong Chinese new user base LOL. This is the 2nd 1-post Chinese user I have seen this morning. On a serious note, it would be rather useful to have multi-language support and then enlist user contribution to translate Unraid to other languages.

So after a lot of testings - all to a Crucial MX300 SSD (8GB test file at 1M blocksize) I noticed dd test the way recommended on github acts rather strange. It reduces write speed a lot (down to 50MB/s on mergerfs mount, 170MB/s direct) but actual write is done in burst at 500MB/s with long waits in between. I redid the test on an NMVe and observed similar behaviours. dsync appears to be the parameter causing this. I can improve dd with dsync performance to 100MB/s by adding cache.writeback (which requires cache.files NOT =off). cache.files=off is 50MB/s regardless of any other tuning Now testing over the network (SMB) from NVMe (passed through to a VM) to mergerfs mount cache.files=off: 150-170MB/s cache.files=off + threads=16: 190-250MB/s cache.files=partial: 60-90MB/s cache.files=partial + cache.writeback: around 125MB/s Note1 : Adding threads=16 doesn't improve performance with cache.files=partial regardless of writeback I did 64GB dd test without dsync (64GB so less RAM cache impact due to file size > free RAM) and all 4 sets of parameters yielded similar average speed (which matches average actual write speed). So I'm sticking to cache.files=off + threads=16 for my all-local mounts.

Have you updated to 6.8.3?

@trapexit: Can you think of any reasons that would cause write to mergerfs mounts to be very slow? Or maybe some tweaks to improve write speed? It seems the slow speed only affects write to mergerfs mount. Writing direct to source folder is more than 5 times faster. My mount command is below. I tried various combinations of options but none offers any improvement. mergerfs /mnt/disks/ssd860evo_2J/backup:/mnt/disks/ssd860evo_6T/backup /mnt/cache/backup/mergerfs -o rw,async_read=false,use_ino,allow_other,func.getattr=newest,category.action=all,category.create=mfs,cache.files=partial,dropcacheonclose=true,minfreespace=32G @DZMM: are you able to do a quick write test to see what you get?

Anyone noticed performance of mergerfs has gone down really badly? I noticed my mount suddenly stops saturating gigabit. So I did a dd test from the console which yielded 45MB/s on the mergerfs mount and 379MB/s writing directly to the same UD drive (that mergerfs was writing to). I don't remember the mount to ever be that slow.

LOL my script is more of a "Hulk! Smash!" approach. virsh shutdown VM1 wait 10s virsh start VM2 wait 10s virsh start VM2 wait 10s virsh start VM2 Since VM1 and VM2 has the same passed-through GPU, it would be impossible to start both VM at the same time. So if the 1st virsh start is before VM1 has been fully shutdown, it would just error out without doing anything and then the 2nd virsh start after 10s and then the 3rd one after another 10s. If VM2 already started, any subsequent virsh start would also error out so they don't do anything.