nicx

Same problem here: "intel-ucode.img" instead of the other file. After rebooting "rc.conf" disappears. What should I do?

@ich777 yes sure, but with ipvlan mode I cannot use my firewall anymore. Thats why I need explicit MAC and IP addresses for some containers.

@ich777 ok thanks again. so it is just not possible to have mixed containers (fixed ip and host ip) in macvlan mode with only 1 MAC address for the host itself presented to the network.

What I want to achieve: Some containers with own IP address, some containers bridged to the unraid host ip. All containers should communicate to the other containers. just did a few tests regarding this: is it possible in ANY way to have fixed IPs for docker containers in my main network without having duplicate IP address for the unraid host in the unifi router when activated "Host access to custom networks" (which is needed in any case for the inter-container-communcation as far as I understood)? I get either eth0 and vhost0 with the same ip address, or br0 and shim-br0. In both cases my Unifi router complains about duplicate IP address in the network. @ich777 any further hints?

@ich777 thanks for that hint. but what is "best practice" when using macvlan? with "bridge" diabled on eth0 "Host access to custom networks" disabled "IPv4 custom network on interface eth0 (optional)" enabled it seems to work. why should I enable "bridge"? why should I enable "Host access to custom networks"?

any solution when using macvlan instead of ipvlan? I have the same problem. and as far as I understood the Unraid howto I should enable both options "Host access to custom networks" and "IPv4 custom network on interface eth0 (optional)" when using macvlan. but with this options enabled, I have the problem with duplicate IP address.

ok just in case someone encounters the same "problem", I now use a user script and run it in the background: rsync -av /mnt/disks/backup/* /mnt/user/backup/ seems to work so far as expected.

@bonienl great plugin. is it possible to add the "preserve symlinks" option to a copy process? should be "cp -P" I think. (-P, --no-dereference) I just realized that if I copy data from one disk to another with a lot of links then the links are "reverted" to real data. The destination disk size was not big enough for that

ok, next question: how should I copy the data preserving the symlinks? and because its a lot of data, how to do it in a way that the process survives even. when quitting the ssh shell for example?

oh shit... I think I found my mistake by myself: I copied the data via the webgui of unraid (Dynamic File Manager). The source data includes a lot of symlinks. I think all symlinks are now "real data" and no more just links. That is why the data is now a lot bigger on the destination disk. Funny coincidence that the compressed data has an identical size as the source uncompressed data with symlinks

here it comes: root@nas:~# zfs get all disk1/backup | grep compress disk1/backup compressratio 1.63x - disk1/backup compression on inherited from disk1 disk1/backup refcompressratio 1.63x - root@nas:~# root@nas:~# zfs list -t all NAME USED AVAIL REFER MOUNTPOINT cache 545G 377G 248K /mnt/cache cache/appdata 70.8G 377G 70.8G /mnt/cache/appdata cache/domains 56.3G 377G 56.3G /mnt/cache/domains cache/icloud 378G 377G 378G /mnt/cache/icloud cache/isos 14.3G 377G 14.3G /mnt/cache/isos cache/share 1.97G 377G 1.97G /mnt/cache/share cache/system 23.7G 377G 23.7G /mnt/cache/system disk1 2.30T 341G 184K /mnt/disk1 disk1/backup 2.30T 341G 2.30T /mnt/disk1/backup root@nas:~# and yes, there is no other data on the disk: root@nas:~# ls -la /mnt/disk1/ total 17 drwxrwxrwx 3 nobody users 3 Feb 23 04:40 ./ drwxr-xr-x 10 root root 200 Feb 22 13:46 ../ drwxrwxrwx 5 nobody users 5 Feb 22 19:50 backup/ root@nas:~# root@nas:~#

Hi, i have turned on ZFS compression on a new array with 1 3tb hdd without parity disk. After turning on, I copied about 2,5 tb data from another identical 3tb disk (unassigned, xfs, without compression) When looking on the compression rate, its abaou 1.7. But when looking on the disk usage, its exactly the same for the zfs disk in the array and the xfs disk unassigned. In my expectation the used disk space should differ in relation to the compression rate. Whats wrong?

@Archonw Danke für dein Feedback. Mit "Ausfallsicherheit" meine ich aber nicht nur Backup. Das habe ich sowieso noch vor regelmässig auf eine externe HD zu machen. Vielmehr meine ich Hochverfügbarkeit, d.h. bei Ausfall einer SSD soll das System weiter laufen. Das wäre meinem Verständnis nach mit deinem Vorschlag nicht gegeben, oder? Oder ist das "ZFS in einem Mirror" genau das? Und bzgl. Trim: Als Cache Pool würde Trim dann funktionieren?

Hallo zusammen, ich möchte gerne einen Unraid Server aufbauen. Als Hardware nutze ich einen Dell Optiplex 5070 mit einer i5-9500 CPU (6 cores) und 4x16GB RAM. Dazu habe ich 2 SSDs mit je 1 TB Kapazität (Samsung Pro 850). Wichtig sind mir natürlich Ausfallsicherheit und Performance. Rein von der Datenmenge her reichen mir 1TB an nutzbarer Kapazität völlig. Jetzt stelle ich mir die Frage, wie ich die SSDs in Unraid konfigurieren soll?! Frage 1: XFS oder ZFS? In meiner Konstellation (nur 2 SSDs) scheint es meinem Verständnis nach keinen Vorteil von ZFS zu geben, daher ist auch XFS ok. Im Grunde also egal. Stimmt das? Frage 2: Array/Pool/Cache? Ich habe mir überlegt einfach ein Array mit beiden SSDs zu erstellen, eine SSD wird die Party, die andere "normale" Array-Disk. Also kein Cache, kein Pool. Ist das so empfehlenswert? Habe ich eventuell Probleme bzgl. "Trim" der SSDs? Ergänzung zu Frage 2: Ich hätte auch noch eine dritte baugleiche SSD hier liegen. Rein aus Stromverbrauchs-Gründen habe ich die erst einmal nicht mit eingeplant, sollte es aber eine Empfehlenswertere Konfiguration geben wo alle 3 SSDs benötigt würden wäre das auch OK. Ich bin gespannt auf eure Ratschläge

no one?

same here, after a reboot of Unraid the usb devices are missing in the vm. checkboxes in the vm config are not ticked anymore. any hint how to solve this?

Hey @JonathanM is this still the case? I just tested it with my Mac client in the same subnet, but got a timeout. Anything else to be aware of?

same here... symbolic links are not workung using in docker. any solution?

I get the error "Out Of Memory errors detected on your server". Attached the diagnostics. Anything I should care? nas-diagnostics-20220414-0730.zip

I tried the same with no luck. And if I check the ntp config on the unraid server I can see that its restricted to 127.0.0.1.

@jonathanm I stumbled across a similar question: I would have liked to use the built-in NTPD server, but it seems this is limited to the local IP, so it is not usable by other clients. Unfortunately this can't be adjusted via GUI. For this reason, this Docker solution could be useful. Or does anyone have an idea how to open the integrated NTPD server without more complex customizations?

hier nochmal ein kurzer Test mit den 250GB Samsung 850 Evo SATA SSD und sysctl vm.dirty_bytes=100000000: root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 77.6048 s, 138 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 70.3208 s, 153 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 71.5436 s, 150 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.52136 s, 194 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.4092 s, 244 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.45699 s, 241 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.45771 s, 241 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.13349 s, 209 MB/s root@nas:~# Mein grundsätzliches Fazit: Ich muss mir überlegen ob ich nicht einfach ein wenig investiere und statt 4* 250GB Evo für Data und 1* 250GB Evo für Parity dann auf 1* 1TB Pro für Data und 1* 1TB Pro für Parity umswitche. Zusätzlicher Vorteil im zweiten Fall: Weniger SSDs für den Beginn, und daher erst einmal kein zusätzlicher SATA-Controller benötigt. Ergo geringerer Stromverbrauch. Wenn das System "wachsen" soll dann wird das aber früher oder später nötig, da nur 3 SATA Ports auf dem Mainboard zur Verfügung stehen (und der dritte belegt wäre doch die 3TB WD Backup HDD) . @mgutt Wäre denn rein aus Performancesicht auch dein Vorschlag mit 1* 1TB Pro als Parity und 4* 250GB Evo als Daten SSDs sinnvoll? Also wie würde sich das denn voraussichtlich auswirken?

Sorry, Modell habe ich ergänzt. Es sind Samsung 850 Pro 1TB SATA SSDs. Und du hast recht, ich hab vergessen das Caching runter zu setzen. Nun hier die Performance Werte mit sysctl vm.dirty_bytes=100000000: root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 20.7396 s, 518 MB/s root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 20.712 s, 518 MB/s root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 20.7638 s, 517 MB/s root@Tower:~#

Ein kurzer Test mit den 1TB Samsung 850 Pro SSDs (sowohl Party als auch Daten-Disk) ergibt folgendes Bild: root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 17.1165 s, 627 MB/s root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 17.1138 s, 627 MB/s root@Tower:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 17.1058 s, 628 MB/s root@Tower:~# Das ist wirklich mal eine krasse Speed Ok, für mich ist es damit recht klar dass das Bottleneck die SSDs sind. Sind halt einfach nicht "Pro".

Hier mal die Testergebnisse mit count=1G: root@nas:~# root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.343877 s, 3.1 GB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.14304 s, 209 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.08903 s, 211 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.13674 s, 209 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk1/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.10374 s, 210 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.346902 s, 3.1 GB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.02571 s, 214 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.11291 s, 176 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.89215 s, 182 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk2/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.09679 s, 176 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.345798 s, 3.1 GB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.46925 s, 166 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.11701 s, 151 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.30008 s, 147 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.30834 s, 147 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.80251 s, 138 MB/s root@nas:~# Dabei ist mir nun aufgefallen dass die Performance mit jedem Test abnimmt, ist richtig schön zu sehen. dazu kommt dass ich all meine Tests mit den Disks stets in der gleichen Reihenfolge durchgeführt habe, also erst disk1, dann disk2 und zuletzt disk3. Also nochmal alle Files gelöscht, 10min pausiert, und gleich mal mit disk3 gestartet: root@nas:~# rm /mnt/disk1/test.img root@nas:~# rm /mnt/disk2/test.img root@nas:~# rm /mnt/disk3/test.img root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.3305 s, 3.2 GB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.01092 s, 214 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.89985 s, 219 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.2154 s, 206 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.14711 s, 209 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=1G 8192+0 records in 8192+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.19081 s, 207 MB/s root@nas:~# und mit count=10G: root@nas:~# rm /mnt/disk3/test.img root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 48.3488 s, 222 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 124.092 s, 86.5 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 51.329 s, 209 MB/s root@nas:~# dd if=/dev/zero of=/mnt/disk3/test.img bs=128K iflag=count_bytes count=10G 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 51.551 s, 208 MB/s root@nas:~# Daraus schlussfolgere ich, das es nicht an einer spezifischen SSD liegt (also z.b. die disk3 irgendein Problem hat), aber wie du sagst @mgutt entweder mit den Lasttest eine Komponente heisser (und dadurch unperfomanter) wird, oder irgend eine grundsätzliche SSD-integrierte Logik (wahrscheinlich auf der Parity SSD) zur Verlangsamung führt. Die eklatanten einzelnen Aussreisser nach unten auf <50MB/s kann ich mir nach wie vor nicht erklären... eventuell läuft hier auch noch irgendein andere Operation auf den SSDs die mir dazwischenfunkt. Rein von den Temperaturen der SSDs steigen diese auf um die 50-55 Grad an sobald ich ausgiebig teste. Deinen Tip mit dem Lüfter werde ich mal ausprobieren Zudem habe ich auch noch 2 Stück 1TB Samsung 850 Pro SSD, diese werde ich mal zu einem Vergleich einbauen und testen. Ich denke wenn Lüfter- und ProSSD-Tests vorliegen, dann sehen wir wohin der Hase läuft Danke auf jeden Fall schon mal @mgutt für deine Tips!