MAM59

in between I have tracked down the issue a bit more.
It looks like the usb plug of the UPS cable was a bit too sloppy. It did not fit in place anymore and due to the vibrations of all these fans and drives, it loses contact now and then.
It seems that the kernel went crazy with all these "on" / "off" transitions of the device and turned off the usb controller.
The flash drive was using a port on the same controller.
 
I have now pulled out the UPS, squeezed the plug a bit with some pliers, and have put it into a raspberry in the same rack as the unraid box.
Installed NUT on the PI in master mode and NUT on UNRAID in slave mode.
We will see if this was the evildoer, the PI does not care about "ports running wild".
 
@JorgeB all ports, sticks and controllers are USB 2.0 only. I have learned my lesson last year already. And the flash drive is not corrupted (yet) at all, it was just disabled.
 

yeah, just use the gui. it is simple
Stop the array, go to network settings, deselect bonding from eth1 first, then
click here, checkmark eth1 and YOU ARE DONE
 
 
 

yeah, thats 3 times faster than 10G Lan :-)))
The real question is: how long can it sustain that speed?
Many cheap drives run out on cache fast and then the write speed drops to ridiculous low (even down to 0) values and slowly resumes afterwards.
For 10G LAN and transfers of bigger files without hickups, you need a very good nvme cache drive.
 

Klar, ich bezog mich nur auf sein eingangs beschriebenes Setup #1 auf 192.168.1.x und #2 auf 192.168.2.x
 

No, it is the same problem as before.
Now you fondle the maximum speed through one hub (which devides it among all connected ports) afterwards the controller in that enclosure does the same.
Both "solutions" slow down drives enormously, they should not be considered at all.
 
The other thing is that the usb driver in linux sometimes gets a hickup and resets the controller and/or the ports. This leads to massive interruptions even with possible loss of data! AVOID AVOID AVOID!!!
 

All ZFS tests here showed up bad results ("slow as a dog"), if in pools or in array drives.
I've reverted to XFS and all is fine again now...
 

you should wait for somebody that can confirm this too.
or, delete network settings from the stick, reboot and try a new config
 

use "Tools->New Configuration" and get rid of all old assignments of the disks.
(this does not delete any data, just the config of the array)
 
Then you can setup your zfs raid and finally add it to the array.
 
BTW: currently ZFS in the array is slow as a dog! you have been warned! Unless a mayor bug fix happens, it is almost unusable because of ridiculously low write speeds. But maybe this does not happen for RAIDs, so far only single ZFS disks seem to be affected from this.
 

I have also Amazon Basics UPS, NUT works. Don't use autodetect, try these settings:
 

Should result into:

Stay away from Jumbo Frames. They once were introduced to limit the amount of CPU time to calculate / check each frame when 1G LAN was introduced.
The idea was that with larger frames, the percentage of the needed header would decrease and less CPU would be hogged.
 
These were the days of "dumb" LAN cards.
Today even the cheapest Realtek one can do the calculations "onchip" and therefor allow "offloading" these things.
 
So, the "Time for Jumbo Frames" is gone for a decade or more already. Today they are just ghosts that need to be included for backwards compatibility reasons.
 
If you did not use them before, don't even think about using them now.
 
(Mesmerizing: "...shhhhh, forget you have ever heard about them.... shhhhhhh....") 😉

Dein /usr/local/bin ist in einer RAM Disk, nach jedem Reboot ist die leer und wird neu aufgebaut (OHNE Deine Skripte).
 
Wenn Du etwas "überleben" lassen willst bei UNRAID, musst Du zu kleinen Tricks greifen.
 
"richtige" Pakete packt man nach /flash (den USB Stick) /extras. Die werden beim Reboot dann automatisch entpackt und landen in den Zielverzeichnissen.
 
Wenn es "nur" um einzelne Dateien wie Skripte geht, muss man entsprechende Kopierbefehle in die Datei /flash/config/go eintragen.
Zb. wie hier in der letzten Zeile:
C:\Users\mam>type \\f\flash\config\go #!/bin/bash # Start the Management Utility loadkeys de-latin1-nodeadkeys /usr/bin/bash /boot/config/cache_dirs -w -u -m 10 -M 20 #cp /boot/config/nginx.conf /etc/nginx/nginx.conf /usr/local/sbin/emhttpd & /usr/bin/bash /boot/config/optional/copyme.sh & Dieses "copyme.sh" kopiert mir die nötigen Dateien von /boot/config/optional rüber nach /usr/local/bin
(Achtung! im laufenden Unraid heißt der Pfad /flash, während der Bootphase /boot !!! Da die Skripte beim Booten ausgeführt werden, muß man hier also /boot verwenden)
Auch das & am Ende ist dringend zu empfehlen, sonst siehst Du u.U. keine UNRAID Gui (zur zusätzlichen Sicherheit habe ich meinen eigenen Kram NACH dem Start der GUI (...emhttp) eingebaut, man will sich ja nicht durch einen blöden Tippfehler selber aussperren...)
 

this is totally normal, people tend to overestimate the capabilities of bonding/trunking/port aggragation.
 
The total speeds do NOT sum up, every connection only uses ONE card. The advantages of bonding only are to prevent line failure (switching over to the "good" card) and load balancing (multiple clients are placed on different card, giving them more total bandwith. But still each client only gets max single card speed).
 
 

You are thinking a bit too complicated 🙂 Clean up.
 
First of all, get a DynDNS Provider somewhere, even your UNRAID Account may be sufficient already if you use the "my servers" plugin. look a the settings there, you may find lines like:
https://192-168-0-4.dd506XXXXXYYYYYYYYa66b1e1.myunraid.net/
 
This is your "official" Name (if you use a different provider, you will get the chance to select your own name/domain).
 
Now go to your GODaddy and change all the CNAMEs you have created to this Name (like "ftp" -> "https://192-168-0-4.dXXXXXX7YYYYYa66b1e1.myunraid.net/" and so on)
 
DONE!
 
Everytime you get a new IP, the plugin will notice it and change your address on unraid.net. The CNAMEs always stay the same.
 
If you use a different provider, you need a means to update this (single) adress record there. Usually the home routers can do this automatically for you, or your provider offers a means to use "curl" or something else to update the data without manual interference.
 

yeah, in the "data" folder of nextcloud (dunno where the docker has mapped it too, I HATE DOCKERS!). There could be a subfolder named after the user, containing old files.
But there should be no problem recreating the same user again, he just will get back his private files then.
 

I still don't see your problem. 1&2 are started.
 
Btw, it is perfectly normal that "Autostart" works after a reboot but not after a manual start of the array.
 
What are you expecting to happen???

leg einfach ne neue VM an mit denselben Werten. Die alte Platte wird weiterverwendet
 

Die Hauptschuppe besteht darin, dass Du versuchst, das SSH Protokoll auf den armen NGINX loszulassen.
 
Der hat damit nix am Hut, der Docker ist nur für HTTP(80) und HTTPS(443) "zuständig". Andere Sachen wie FTP oder eben SSH kann er gar nicht tunneln.
 
NGINX ist ein Webproxy, was Du suchst ist ein "Portproxy".
 
Werf mal einen strengeren Blick in Deinen Router. Viele (z.B. Fritzbox) bieten die Möglichkeit, Ports weiterzuleiten ("Freigabe") und dabei auch andere Zielports ("Umleitung") zu wählen.
 
Ach ja: Port 22 ist von UNRAID selber belegt, könnte eh nicht umgelenkt werden wenn Du nicht auf Fernadministration verzichten möchtest.

Yeah, and a very simple too: DELETE the default Gateway entry on ETH1!
It does not belong there at all, only ONE default gateway can be active at a time. And only the card that is connected to the internet router should have one.
 
But I don't understand the ping if the port is down... or are you just pinging internally??? if yes you just get an echo from the driver himself, not from the card.
 

yeah, this happens if you play around with letsencrypt too much and too often.
 
The good thing: there is nothing wrong with NPM, UNRAID or the container.
 
You need to do 2 things to get it done:
 
1) be patient, you are blocked for at least 1hr, no way to speed it up
2) get your "jelly..." domain properly announced in the external DNS servers. You cannot get any cert for internal only domains. Go to you DNS provider, add a CNAME for jelly... to your current external ip address (or add an A or AAAA record if you are using static addresses in the real world)
 
check with "nslookup jelly.... 8.8.8.8" before you do your next try and make letsencrypt become mad for you again.
The nslookup should be able to get an address record that points to your box. If not, FIX IT!!!
(repeat until it works)
 

Can depend on your server's bios settings. (BTW: Intel does not sell any servers ?!?!??)
 
Some ship with a 2+2 configuration, 2 Ports are forwarded to booted OSes, the other 2 are reserved for ISCSI connection (bootable).
 
Check your manuals.
 
(you may also find a 5th port somewhere, this is for "management access" only. Of course, this also depends on your server...)
 

Grundsätzlich gehören keine SSDs / NVMes ins Array, Eben wegen fehlendem Trim. Das Array macht aber auch nur Sinn, wenn es von mindestens einer Paritätsplatte gesichert wird.
Als "Cache" brauchst Du die NVMes auch nicht, denn sie würden ja nix schneller machen.
 
Was Dir bleibt sind eben einfache Pools mit jeweils einer NVMe (nicht beide in einen Pool packen, dann wird da ein RAID Array raus und die Hälfte der grossen NVMe bleibt ungenutzt, Du hast dann nur 2Tb übrig! (jaja, man KANN das dann hinterher wieder korrigieren, aber erstmal ist das Kind in den Brunnen gefallen und der Umbau danach geht nicht ohne Löschen der Platten ab))
 
Eigentlich ist UNRAID gar nix für Dich, alle "guten" Features willst Du nicht bzw. kannst Du nicht gebrauchen.
 

What you see is the effect of low ram+slow cpu+slow disks (no cache drive). Its a combination of all of them, not a single problem.
During File Copy to UNRAID, incoming data is written out to disk (the parity calculation is almost nothing, but the parity write then takes away 50% speed). If the disks cant keep up, data is put into ram until full (btw, UNRAID shows 100% CPU usage during this "no free io slot" period. This is a false reading, look at the CPU temperature, if it keeps low, the io is blocked, not the CPU overloaded). Finally it sends a "STOP PLEASE!" packet to the sender.
Then it takes some time to write out the RAM content to the disk, this is the "stalled" period you see. After this it sends a "YOU MAY CONTINUE" packet and transfer starts again.
 
Terracopy and Windows Copy have their own approach how to handle this situation. Windows seems to be more polite, but at the end it is usually much slower. Anyway, the stall is no bug, its a must.
 
You may install the "Tips & Tweaks" Plugin, there you find two settings to play with.
"vm.dirty_backround.ratio" and "vm.dirty.ratio" control the level of how much ram is used to cache before io starts and how much  ram must be free again until the blockade is realeased.
If you buffer too much data in ram, the duration of the stalls will be longer (needs more time to free up more ram from data). If you set them to very low value, transfers will look to be smaller, but stall do not happen anymore or are really short. There is no "good" setting for them, it depends on your hardware and you LAN. You need to experiment a bit.
 
The faster your LAN gets, the more visible this effect will be. Even a cache drive (for writing only, I like to see a read cache too) does not fully compensate for this. For 2,5G LANs a SATA SSD might be sufficient, for higher speeds you need a PCIe NVMe drive. But even then stalls can happen if the cache is not capable to hold the speed for sustained writes.
 
 

you must have done something wrong when you have installed the ssd cache.
Normally these folders are created automatically on the "cache" pool
 
Anyway, not really a big deal, but you have to keep in mind that /mnt/user/... is just a virtual path, you cannot create folders there.
Instead create /mnt/cache/appdata and /mnt/cache/system, automagically they will appear as shares in the gui and the mapping will be done.
 
Use either the console or use "mc" from the gui.
 

Das sollte problemlos gehen.
Stoppe das Array, lege einen neuen Pool an mit dem Namen "Cache" (wobei, der erste Pool heißt eigentlich immer automatisch "Cache"), weise die SSD dem Pool zu und starte das Array wieder.
Der Pool sollte dann automatisch gemountet werden und nicht nach Neuformatierung schreien (Wenn doch, DANN STOP!!! und alles wieder zurück!).
 
Anschließend kannst Du einfach bei Deinen Shares wieder die Cache Einstellung auf "Yes" oder "Prefer" oder, was Du eben willst, setzen.
 
(PS: Du kannst viele Pools anlegen, alle mit eigenem Namen. Die müssen nicht zwangsläufig "Cache" heißen, Du kannst bei den Shares beliebige Pools zuordnen. Aus historischen Gründen heißt der erste halt immer "Cache")
 

Jumbo Frames were a try when 1G LANs came up. The basic idea behind them was that larger frames need fewer headers so the throughput would increase.
It does, but not really much. And when LAN cards started to manange headers themselfs "in hardware" the header thing got even less important.
Today the benefit from Jumbo frames is almost not existent anymore. You can perfectly live without them. They do not harm unless your transmissions are not clear and need retries (larger packets need longer times to be resend). But they also do not improve anything.
IF you want to use them, you need to configure ALL comunication partners (PC - switch - PC) to use the same MTU, else you slow down the transmissions because the computers need to find out by try & error (aaaah... "resend & fragment") which value is suitable for the partner.
And, to make things even more complicated, some count the MTU without headers ("9000"), some count them in ("9114"). You have to find out which setting is correct for your cards/switches.
Nice job if you want to kill a rainy day, but also not needed at all.