tourist

Can I uninstall just one feature of NerdTools, without uninstalling NerdTools? You supply python3-3.9.18-1. Community app 'Python 3 for UNRAID' provides 3.13.1. When I go to install 'Python 3 for Unraid', it complains that Python 3 is already installed, and to check /boot/extra. I did and found python3-3.9.18-x86_64-1_slack15.0_nerdtools.txz. That matches: root@UNRAID:~# python3 -V Python 3.9.18 But I like NerdTools for its other features. I'd rather not throw it out for this one issue, and I don't want to run Python from Docker because I don't want the hw virtualization penalty. Any help appreciated.

So, I just upgraded from 6.11.5 to 6.12.10 (very late, I know) and discovered that my pool and shares are gone. I need to recreate them. I see the drives belonging to the original plugin pool are listed under Unassigned Devices, and their type is zfs. There should be some ZFS features in the web gui of 6.12.x, right? I'm not finding any. Shelled into the server I see `zpool` and `zfs` commands are available. The presence of ZFS in the web gui is mentioned 6.12.0 release notes and related blog post, and the very sparse docs. root@UNRAID:~# zpool version zfs-2.1.14-1 zfs-kmod-2.1.14-1 root@UNRAID:~# zfs version zfs-2.1.14-1 zfs-kmod-2.1.14-1 I also see that the old ZFS plugin is now under "Plugin File Install Errors" sub-tab of Plugins tab. I removed that and rebooted, but still no ZFS in the web gui. The files are still present under /boot/config/plugins-removed/ root@UNRAID:~# ls -l /boot/config/plugins-removed/ total 72 -rw------- 1 root root 1606 May 12 2022 ZFS-companion.plg -rw------- 1 root root 19462 May 30 2021 nvidia-driver.plg -rw------- 1 root root 25544 May 12 2022 unRAID6-ZFS.plg -rw------- 1 root root 2560 May 13 2022 zfs.master.plg `dmesg` shows one message about the ZFS kernel module, appears to have loaded normally- [ 38.861784] ZFS: Loaded module v2.1.14-1, ZFS pool version 5000, ZFS filesystem version 5 syslog shows a few lines- Dec 3 18:19:48 UNRAID kernel: ZFS: Loaded module v2.1.14-1, ZFS pool version 5000, ZFS filesystem version 5 ... Dec 3 18:20:15 UNRAID emhttpd: shcmd (4): modprobe zfs Dec 3 18:20:21 UNRAID emhttpd: shcmd (33): /usr/sbin/zfs mount -a System resources all good- root@UNRAID:~# uname -a Linux UNRAID 6.1.79-Unraid #1 SMP PREEMPT_DYNAMIC Fri Mar 29 13:34:03 PDT 2024 x86_64 AMD Ryzen 9 3950X 16-Core Processor AuthenticAMD GNU/Linux root@UNRAID:~# cat /proc/meminfo | head -3 MemTotal: 131826180 kB MemFree: 83573768 kB MemAvailable: 94084944 kB root@UNRAID:~# df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 65895996 1480740 64415256 3% / tmpfs 131072 5632 125440 5% /run /dev/sda1 15309840 1093112 14216728 8% /boot overlay 65895996 1480740 64415256 3% /lib overlay 65895996 1480740 64415256 3% /usr devtmpfs 8192 0 8192 0% /dev tmpfs 65913088 0 65913088 0% /dev/shm tmpfs 131072 740 130332 1% /var/log tmpfs 1024 0 1024 0% /mnt/disks tmpfs 1024 0 1024 0% /mnt/remotes tmpfs 1024 0 1024 0% /mnt/addons tmpfs 1024 0 1024 0% /mnt/rootshare /dev/md1p1 1999421892 1204474196 794947696 61% /mnt/disk1 /dev/md2p1 976284628 495825080 480459548 51% /mnt/disk2 shfs 2975706520 1700299276 1275407244 58% /mnt/user0 shfs 2975706520 1700299276 1275407244 58% /mnt/user /dev/loop2 20971520 14479928 6099592 71% /var/lib/docker /dev/loop3 1048576 5512 924824 1% /etc/libvirt tmpfs 13182616 0 13182616 0% /run/user/0 Not sure what could have caused ZFS to get dropped from the GUI. Has anyone else experienced this? Any ideas? Am I safe to recreate the pool from CLI? Should I worry about the apparently missing GUI elements? -tourist

Much thanks for creating this, it's been very helpful. Question: what about the 'Sign Up To Cloud' button in the upper-right? I clicked it, gave an email, got an email taking me to directions for all the ways to connect my systems to netdata's cloud storage. One of them was for Docker, and the main difference seemed to be that it specified a base 64 rando identity param named NETDATA_CLAIM_TOKEN, and another NETDATA_CLAIM_URL=https://app.netdata.cloud So I edited my netdata-glibc config and added those at the end of Extra Parameters- --runtime=nvidia --cap-add SYS_PTRACE --security-opt apparmor=unconfined -e NETDATA_CLAIM_TOKEN=rando-string-goes-here -e NETDATA_CLAIM_URL=https://app.netdata.cloud Clicked apply, container restarts, however the 'Sign Up To Cloud' button doesn't disappear, and following signin at https://app.netdata.cloud/spaces it says I have no nodes. Has anybody else figured out how to link netdata-glibc with netdata.cloud?

The coolest thing about ZFS is it can create virtual block devices. What I ended up doing was using the 2nd form of `zfs create`, which creates a zfs dataset at a virtual block device /dev location- zfs create -s -V 1T -o volblocksize=4096 -o compression=lz4 mypool/vmvol This created `/dev/zd0`. Then I created a new VM, Ubuntu Server 20, using that /dev/zd0 over SATA. It performs well, for larger block sizes. For database writes of batches of large rowsets (20 MB, 100K rows), it's quite fast, ~450 MB/sec over time, as UNRAID's write cache becomes exhausted. When I need to expand the ZFS pool, I can add new drives, once raidz drive expansion hits production. UNRAID has been good to me. If I built separate machines, 3x more money spent. If I virtualized in AWS, $3k per month (AWS estimate). It paid for itself in two months.

I ran a few more tests, at bigger block sizes, and got reasonable performance. Bigger blocksize = better performance, right up to the range of what my tiny ZFS array is capable of. The app for this particular VM is gonna be batch writing big chunks of rows to MariaDB tables, so now I think it'll be fine. (I know that the bigger MB & GB/s figures are due partly to write caching. In longer dd tests (500GB) it averaged out to near the native write performance.) I'll continue benchmarking just for the heck of it. ps. I did allocate a 2.5 Gbps ethernet adapter to this VM, but haven't set it up yet. I take it this would be done using ISCSI, targetcli etc? I wonder if performance would be any better. $ dd if=/dev/zero of=./test99_bs8K_c500K.dat bs=8K count=500K oflag=direct status=progress 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 86.478 s, 48.5 MB/s $ dd if=/dev/zero of=./test99_bs16K_c250K.dat bs=16K count=250K oflag=direct status=progress 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 49.7929 s, 84.2 MB/s $ dd if=/dev/zero of=./test99_bs32K_c125K.dat bs=32K count=125K oflag=direct status=progress 4194304000 bytes (4.2 GB, 3.9 GiB) copied, 32.96 s, 127 MB/s $ dd if=/dev/zero of=./test99_bs64K_c62.5K.dat bs=64K count=62500 oflag=direct status=progress 4096000000 bytes (4.1 GB, 3.8 GiB) copied, 22.2345 s, 199 MB/s $ dd if=/dev/zero of=./test99_bs128K_c31.25K.dat bs=128K count=31250 oflag=direct status=progress 4096000000 bytes (4.1 GB, 3.8 GiB) copied, 12.7734 s, 321 MB/s $ dd if=/dev/zero of=./test99_bs256K_c15625.dat bs=256K count=15625 oflag=direct status=progress 4096000000 bytes (4.1 GB, 3.8 GiB) copied, 10.2312 s, 400 MB/s $ dd if=/dev/zero of=./test99_bs512K_c7813.dat bs=512K count=7813 oflag=direct status=progress 4096262144 bytes (4.1 GB, 3.8 GiB) copied, 4.02221 s, 1.0 GB/s $ dd if=/dev/zero of=./test99_bs1M_c3906.dat bs=1M count=3906 oflag=direct status=progress 4095737856 bytes (4.1 GB, 3.8 GiB) copied, 3.28692 s, 1.2 GB/s

Pass through a physical NIC from the unraid host to a VM? That will bring faster transfer from a ZFS dataset on unraid with the VM? Unobvious [to newb me], so why not, I'll try it.

Hullo.. I'm about one year in with unraid on a system I built to run VMs and Docker apps (AMD 3950X, MSI X570, 128 GB RAM, 4 TB SSD array, 2x RTX 2070 SUPERs, GeForce GT 710). Really enjoying unraid and CA. I needed more storage, so I bought 4x Seagate X18 18TB drives, figuring I'd stripe them with ZFS or RAID. I tested the new drives a bit, first, formatting them ext4 on unraid cli (~280 MB/sec w/1M writes to a single drive, ~same for reads -both via dd with iflag/oflag=direct, clearing unraid's filesystem cache before the read test). Then I tested with an Ubuntu VM, passing the device in as a secondary drive, with raw and VirtIO, and got 245 MB/sec writes, about the same for reads. I thought, "Okay, that's close enough to spec. Maybe I could run them in a raidz2 pool and find a method for passing through a zfs dataset that's performant." So I created a raidz2 pool from the four drives. With caching disabled, dd if=/dev/zero of=./test.dat bs=1M count=40000 oflag=direct which writes at ~404 MB/s, reads ~496 MB/s. Not bad! In the same pool I created a 1 TB /dev/zvol block device, then created a Ubuntu 20 VM using the new block device as its primary, /dev/zd0, with VirtIO. Performance was abysmal. Writes ~35 MB/s, reads ~37 MB/s (bs=1M count=40000 oflag=direct). I tried accessing another dataset on the same zpool, via SMB, from another Ubuntu VM on the unraid host, and got writes at 20 MB/s, reads 18 MB/s (again bs=1M etc). Is there a better way? (What causes such slowness??) I know about passing in the /dev/sd* drives to let a guest VM create its own zpool, but I wanted to share the darn thing across VMs and not keep it in just the one VM. I've seen the idea of running TrueNAS in a VM -I imagine it'll be quick for that VM, because it'd be passing the devices through, but wouldn't peer VMs suffer the same lag as my previous efforts? Is it worth going down that path? What's your best method and result for sharing ZFS across VMs?

My F@H docker image was running just fine... then after a reboot the container starts, but the web console times out (http://10.0.0.52:7396/) The netdata plugin shows that nothing much is happening on the GPUs or CPU, so I guess that my F@H somehow got broken, and is pretty silent about why. Stopping and starting again doesn't change. GPU IDs remain the same as before the reboot. No errors about GPUs or drivers, and the GPUs are recognized. Latest logs here: https://pastebin.com/g1vm41Qy I've scanned this thread, and upgraded to the latest, but no change in behavior. I've looked for logs besides those produced directly by the F@H control client, under /var/log, but nothing interesting. Posting here in the hope that one of you recognizes the pattern and can nudge me in the right direction. Cheers.