limetech

Try this: change the name of config/network-rules.cfg to config/network-rules.cfg- (or anything) and then reboot.

Well, please send me your passphrase in PM. You can change the alpha-numerics around but don't change the length or position of any non-alphanumerics.

When you originally encrypted your devices you were running 6.8.1 and you specified "Passphrase" method of specifying the key... is this exactly correct?

To verify, if you 'cat keyfile' you should see your exact passphrase with command prompt string appended (because no newline in key), eg, if key is 'mypassphrase123' you should see: root@Tower:~# cat keyfile mypassphrase123root@Tower:~#

You would have to use echo -n 'passphrase' > key and this only works if no single quotes in your passphrase.

Does your passphrase consists only of the 95 printable ASCII characters? https://en.wikipedia.org/wiki/ASCII#Printable_characters In your text file, are you sure there is no End-of-line character, such as null byte or newline?

The syslog shows x2 attempts to enter passphrase, did you try keyfile method?

Please list the exact steps you took. For example I'm guessing you did this: Install Unraid version 6.8.1 Formatted disk(s) using "xfs-encrypted" file system type. Selected "passphrase" as Encryption input. Typed your 64-char passphrase Clicked the Show passphrase box and verified typed correctly Use mouse to select/copy the passphrase string Pasted the string to a text file open in another window on your PC. Started array. Formatted disk(s) Copied data to disk(s) Stopped array Rebooted server Typed passphrase and clicked Start => wrong key Pasted saved string from text file to passphrase and clicked Start => wrong key Specified "Keyfile" Encryption input, selected text file, clicked Start => wrong key Please corrrect what I got wrong above. Would also help if you posted diagnostics.zip

The patch modifies source code of the Linux kernel. To make these changes "configurable" would take way too much effort. Theoretically someone could create and maintain a "amd-reset-bug-build" version of the kernel with this patch much like the unofficial "nvidia-build" of the kernel.

It should make very little difference in this test. This can be alleviated fairly easily. This is the big question: how significant is significant and how big is the number of files? A logical guess is that very few users have large enough directories where any of this makes a difference. (that is between 6.7.2 and non-HL 6.8). For the users where this is an issue, yeah that's unfortunate. The core of the issue has to do with aging cached attribute information in both the kernel FUSE module and the user-space FUSE node table. This determines how many back/forth transactions there are between kernel space and user space for each file system operation. The more transactions, the slower it gets. We can spend many hours trying to further improve this, but in the end, are those hours better spent adding, for example multiple-pools with zfs support?

Yes. Granted, passing the usb controller is a pain-in-the-neck to configure but once it's done it's done. You have to go to Tools/System Devices and find your USB controllers. Next you have to determine which usb ports are connected to those controllers and decide which one to pass through, making a note of the PCI ID which will be of the form "nn:nn.n". You then specify that ID in the config/vfio-pci.cfg file and reboot. This tells the Linux kernel to ignore this controller. You can now go to the VM edit page and you'll see the USB controller checkbox at the bottom under "Other PCI devices". In my case, my motherboard has a set of 4 USB3.0 ports on the I/O panel. It was easy to find that in System Devices: IOMMU group 19: [1022:145c] 0c:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) USB 3.0 Host Controller My config/vfio-pci.cfg file looks like this: BIND="0c:00.3" And at the bottom of the VM edit page is: The win10 VM now sees that USB controller and the Logitech receiver plugged into one of the ports. (The unchecked Logitech wheel mouse, UPS, and Dell keyboard are for host (Unraid OS) use).

That's a little unfair. Individual USB assignment has always been problematic - on again/off again. It stems from interaction between qemu/kvm, both of which we keep up with latest releases, both of which we have no control over. I told you the most reliable method to get USB devices to work is to pass through the entire controller. It's exactly what I do with the VM running win10 that I'm typing this with, because I too have seen cases where a logitech wireless receiver simply didn't work reliably, but passing through the controller itself is very reliable.

Most reliable way to deal with USB devices is to pass through the entire controller to the VM.

Can you add results for 6.7.2 as well? Using your script this is what I get with hard link support disabled: 10000 files Writing files Benchmarking disk: 0.03 Benchmarking SHFS: 0.15 20000 files Writing files Benchmarking disk: 0.06 Benchmarking SHFS: 0.32 30000 files Writing files Benchmarking disk: 0.08 Benchmarking SHFS: 0.49 40000 files Writing files Benchmarking disk: 0.11 Benchmarking SHFS: 1.05 50000 files Writing files Benchmarking disk: 0.14 Benchmarking SHFS: 1.35 60000 files Writing files Benchmarking disk: 0.16 Benchmarking SHFS: 1.64 70000 files Writing files Benchmarking disk: 0.19 Benchmarking SHFS: 1.93 80000 files Writing files Benchmarking disk: 0.22 Benchmarking SHFS: 2.27 90000 files Writing files Benchmarking disk: 0.25 Benchmarking SHFS: 2.64 100000 files Writing files Benchmarking disk: 0.27 Benchmarking SHFS: 3.02 110000 files Writing files Benchmarking disk: 0.31 Benchmarking SHFS: 3.38 120000 files Writing files Benchmarking disk: 0.34 Benchmarking SHFS: 3.97 130000 files Writing files Benchmarking disk: 0.37 Benchmarking SHFS: 4.56 140000 files Writing files Benchmarking disk: 0.40 Benchmarking SHFS: 5.32 150000 files Writing files Benchmarking disk: 0.42 Benchmarking SHFS: 5.78 160000 files Writing files Benchmarking disk: 0.46 Benchmarking SHFS: 6.54 170000 files Writing files Benchmarking disk: 0.48 Benchmarking SHFS: 7.23 180000 files Writing files Benchmarking disk: 0.51 Benchmarking SHFS: 8.30 190000 files Writing files Benchmarking disk: 0.54 Benchmarking SHFS: 8.83 200000 files Writing files Benchmarking disk: 0.57 Benchmarking SHFS: 10.56 210000 files Writing files Benchmarking disk: 0.60 Benchmarking SHFS: 10.96 220000 files Writing files Benchmarking disk: 0.63 Benchmarking SHFS: 11.64 230000 files Writing files Benchmarking disk: 0.63 Benchmarking SHFS: 13.56 240000 files Writing files Benchmarking disk: 0.66 Benchmarking SHFS: 14.70 250000 files Writing files Benchmarking disk: 0.73 Benchmarking SHFS: 15.26 Quite a bit different than your results, not sure why.

Note: this is a subtle bug and does not exist in 6.7 release. It exists in 6.8 because we no longer write the passphrase to a file.