mrpops2ko

so whilst mover i think should still work, just using shfs instead of mergerfs - if you do want to make use of a mover which is based upon using mergerfs i've attached an example of muffins script now in order to use this, you'll need to set up another mergerfs pool of just your hdds, i did this mergerfs -o noatime,category.create=ff,category.search=ff,func.getattr=newest,dropcacheonclose=false,passthrough.io=rw,cache.files=auto-full,cache.writeback=false,minfreespace=105G,inodecalc=hybrid-hash,never-forget-nodes=true,lazy-umount-mountpoint=false,cache.readdir=true,cache.symlinks=true,cache.statfs=120,cache.negative-entry=120,cache.attr=1800,cache.entry=1800,fsname=mergerfs-cold '/mnt/disk1:/mnt/disk2:/mnt/disk3:/mnt/disk4:/mnt/disk5:/mnt/disk6:/mnt/disk7:/mnt/disk8:/mnt/disk9:/mnt/disk10:/mnt/disk11:/mnt/disk12:/mnt/disk13:/mnt/disk14' /mnt/addons/mergerfs-cold the following bellow is a docker container which will run on startup and then stay up and rerun daily at 3am checking to see if you meet the criteria for movement to occur in it im moving from `/mnt/nvme_cache` (my nvme ssd cache) to `/mnt/addons/mergerfs-cold` which is just my regular `/mnt/addons/mergerfs` without nvme / ssd's in it the script is both better and worse than the advanced mover script. it is better because it uses copy on write techniques to avoid issues with file transfers (it will copy / rename / do size comparison etc checks / then delete and fix the naming) which is better in scenarios where powercuts happen or just various issues. the bad sides to it, are that it doesn't have the advanced ability to pick based upon mtime (so moving the oldest files) services: mergerfs-cache-mover-nvme: image: ghcr.io/monstermuffin/mergerfs-cache-mover:latest container_name: mergerfs-cache-mover-nvme privileged: true environment: INSTANCE_ID: nvme CACHE_PATH: /mnt/nvme_cache BACKING_PATH: /mnt/addons/mergerfs-cold SCHEDULE: "0 3 * * *" THRESHOLD_PERCENTAGE: 95 TARGET_PERCENTAGE: 85 MAX_WORKERS: 1 LOG_LEVEL: DEBUG KEEP_EMPTY_DIRS: false EXCLUDED_DIRS: >- appdata, domains, system/docker, libvirt, shared_env volumes: - /mnt:/mnt:rw,rslave - ./var/log:/var/log:rw restart: unless-stopped i kind of would like to have mtime ability, so i might look into adding it. always scary modifying scripts that are touching files though lol

just thought i'd comment on here and document my setup a little so that anybody who wants to make use of the information can and if they have any suggestions or improvements please poke / quote me and i'll edit the post. as just a general entrypoint note for someone considering this, it genuinely seems to solve all the problems with unraids FUSE implementation which sees 30x slower reads https://www.phoronix.com/news/Linux-6.9-FUSE-Passthrough i have very predictable workloads, and the disappointment with Unraid from the start in relation to its poor performance (SHFS) is finally gone. The only gotcha i've found so far is in relation to hdd activity. you'll generally see a power increase (less spin down on hdd's) in using this because of how mergerfs walks the directories when looking for files. this probably can be mitigated a lot through the policies but currently i don't have good insight into ones which would. hopefully this thread can help us groupthink some. this problem is also documented here https://trapexit.github.io/mergerfs/latest/faq/limit_drive_spinup/ I do think though that there exists a series of potential options which can fix this, we just need to properly go through and figure them out and create something we can all live with. some of the options are tradeoffs in greater performance for lesser efficiency. file placement and general grouping is also another, i'm sure we can move directories around to better localise them and prevent spinups. i need to check over the mergerfs scripts some more because some exist to do that i believe. we also have that unraid plugin which can do similar in terms of the scatter / gather of files. even with that gotcha i'm still going with this, it turns your system into actually being usable again for some stats, look at this ^ gigabit saturated connection download utilisation, the best part being no huge 100% CPU usage spikes anymore and just regular, what you'd expect performance. not the crippled and diminished performance of SHFS In using mergerfs the CPU utilisation at LOAD was LOWER than SHFS at IDLE SHFS IDLE: 10-13% MergerFS IDLE: 1% SHFS LOAD: 28-35% MergerFS LOAD: 13% As always the docs should be the source of truth for everything, this is just my first attempt at fumbling through them https://trapexit.github.io/mergerfs/latest/ After installing the plugin, in my /etc/mergerfsp/array_start.sh i've placed #!/bin/bash mkdir -p /mnt/addons/mergerfs sleep 1 # Put any commands to run at ARRAY START (after disks mounted but services not yet started) here! mergerfs -o category.create=ff,category.search=ff,func.getattr=newest,dropcacheonclose=false,passthrough.io=rw,cache.files=auto-full,cache.writeback=false,minfreespace=105G,inodecalc=path-hash,never-forget-nodes=true,lazy-umount-mountpoint=false '/mnt/nvme_cache:/mnt/cache:/mnt/disk1:/mnt/disk2:/mnt/disk3:/mnt/disk4:/mnt/disk5:/mnt/disk6:/mnt/disk7:/mnt/disk8:/mnt/disk9:/mnt/disk10:/mnt/disk11:/mnt/disk12:/mnt/disk13:/mnt/disk14' /mnt/addons/mergerfs sleep 15 exportfs -i -o fsid=110,async,no_subtree_check,sec=sys,rw,all_squash,insecure,anonuid=99,anongid=100,nohide,crossmnt 192.168.xx.xx:/mnt/addons/mergerfs/data exportfs -i -o fsid=110,async,no_subtree_check,sec=sys,rw,all_squash,insecure,anonuid=99,anongid=100,nohide,crossmnt 192.168.xx.xx:/mnt/addons/mergerfs/data exportfs -i -o fsid=110,async,no_subtree_check,sec=sys,rw,all_squash,insecure,anonuid=99,anongid=100,nohide,crossmnt 192.168.xx.xx:/mnt/addons/mergerfs/dataand i've also got in the dropdown menu to unmount on array stop the exportfs is used to NFS export it, i've found NFS performs better in general than SMB (lower cpu usage and better at small files) but you can use either. theres some previous posts on how to set up SMB. who knows I might switch because NFS seems to be more edge cases in the docs but i'll wait to see if they manifest for myself here are my settings and justification for them. in general what i want my setup to look like, is that files get placed onto the nvme ssd and then i can use other tooling (the advanced mover plugin etc) to place them onto the array Setting Commentary passthrough.io=rw this is the big one, native FUSE passthrough and thats where we get almost all the speed from category.create=ff this i've got a high confidence that will function how i want, since it walks the order you place on the mount so it will always create files on my nvme ssd first category.search=ff this is the default one but its likely something i'm going to change i'm just not 100% sold on all the options yet and need to consider their implications. its really bad at times because if you have say a file on disk 10, it'll walk through and spin up disks 1-9 checking for it before finding it on disk 10 func.getattr=newest another one that im 50/50 on. it is really useful for what it does (it returns the newest file, since we are using first found in the search if you have multiples of the file then it could return an older one without it since it stops on the first found, but in how it does it means that it has to search through all the disk. this is one i think i'll experiment with and change to reduce spinup after i've audited a bit more dropcacheonclose=false if you turn this on, you'll end up purging your linux native page cache a hell of a lot more and just having tons of ram just being unused. keep it off unless you have some kind of high memory pressure. cache.files=auto-full we use passthrough.io so its needed cache.writeback=false needed for passthrough.io minfreespace=105G set whatever you want but I think its good that you don't fill up an entire disk. bad things can happen when you do and it avoids headaches inodecalc=path-hash nfs related recommendations in docs never-forget-nodes=true nfs related recommendations in docs lazy-umount-mountpoint=false nfs related recommendations in docs my NFS export settings i'm lead to believe by the documentation are wrong but i've yet to experience a problem with them. i'm going to keep going with them until I do experience those problems or else i'll keep what I have and try to make it work around what I want. theres more settings in here that I will likely play around with https://trapexit.github.io/mergerfs/latest/faq/limit_drive_spinup/ but for now i'm pretty happy with things the way they are. in terms of how you interact with everything, all your docker containers that would otherwise have been using /mnt/user should now be using /mnt/addons/mergerfs as in the example. also remove your share exports for the old /mnt/user stuff in the shares tab. turn off NFS / SMB share exports in the share menus and do them yourself in their respective places and script it. I am noticing on odd occasions my parity drive spinning up, which is an indicator that something is being written to the underlying array filesystem that shouldn't be. another thing that i'll need to dig into. i'm suspecting its something related to updating directory last accessed times because i noticed some of those changed even though I never did use the files. possibly the search category being existing path first found rather than just first found and coupling the folders together more cleanly could help with the spinups - nobody wants 10 drives to spin up when browsing a directory of 10 songs. the problem with existing path first found though would be that i am using mover tuner to migrate from nvme > array which wouldn't work well for this particular task since it'll just dump everything into the disk with the most space (or at least thats how i've previously set it up). maybe using the shares tab and the watermarks it could more cleanly map out, but another option which i've read others do is to create something like unraids /mnt/user and /mnt/user0 where the user is ssds + hdds and user0 is just hdd's. then you can run some kind of rsync migration script from one to the other and it'll follow mergerfs policies on file creation (and you set up another mergerfs user0 pool with different settings, you'd want the category.creation to be the same as your /mnt/user category.search, so that it ends up being path preserving or just putting the files in such a way that it reduces spinups) anybody who has any insight or tips on getting this all running better, please don't be shy and comment EDITS: modified dropcacheonclose=true to false edit2: the + are things i've added and - are things i've removed + noatime - func.getattr=newest + cache.readdir=true + cache.symlinks=true + cache.statfs=120 + cache.negative-entry=120 + cache.attr=1800 + cache.entry=1800 most of these are aimed at keeping disks spun down more / longer

one solution can also be to use https://forums.unraid.net/topic/144999-plugin-mergerfs-for-unraid-support-topic/ it seems as though unraid / limetech long abandoned JBOD users, so waiting on them to do something meaningful to support them is a lesson in frustration (as it seems most of these feature requests are, theres 1000's of really good ones spanning decades that are completely ignored)

sure but doesn't even the greatest journey start with a single step? adding zfs also was no small feat but it exists within the unraid ecosystem. if the dev ethos is only to look for small flag modification style changes to see wins then that needs looked at. mergerfs with only a single dev implemented this and people saw significant performance uplift. you'd imagine a paid product, with an entire dev team would have more collective capacity to integrate it. i really dont want to spend the time to migrate away but it becomes a real problem for a lot of us who have mixed workloads of mostly random read. unfortunately those guys are most effected and would really benefit from a 35x performance uplift.

Way back in 2023 / 2024 we got massive improvements to FUSE which haven't propagated to unraid. In the year of our lord 2026, are they even at least on the roadmap? can we get some love for the array users who don't want to go down the path of striping? its been the biggest bottleneck for the past decade+ and we have solutions that massive increase performance now, just waiting for unraid to implement. LWN.netFUSE passthrough for file I/OThere are some filesystems that use the Filesystem in Userspace (FUSE) framework but only to pr [...] https://kernelnewbies.org/Linux_6.9#Faster_FUSE_I.2FO This was all benchmarked back in 2024 and the results were staggering then, and still are now. https://www.phoronix.com/news/Linux-6.9-FUSE-Passthrough Can we get this implemented so we can see a 300%+ increase in read speeds and 1000% increase in write speeds? this one issue is one of the biggest gripes of performance for most people using unraid. adding this solves it and we gain upwards of 10x performance uplift from it.

upgraded from the 7 beta to 7.1.4 having some issues where now every time i have to log into the web ui - it isn't seeming to store cookies with saved password. i guess i'll try delete the cookies and try again whats more concerning is that i got a kernel panic Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: exception Emask 0x10 SAct 0x106c0 SErr 0x0 action 0x6 frozen Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: irq_stat 0x08000000, interface fatal error Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: failed command: READ FPDMA QUEUED Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: cmd 60/c8:30:b8:b7:5f/01:00:77:00:00/40 tag 6 ncq dma 233472 in Jul 21 21:04:39 192.168.1.3 kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: status: { DRDY } Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: failed command: READ FPDMA QUEUED Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: cmd 60/00:38:80:b9:5f/04:00:77:00:00/40 tag 7 ncq dma 524288 in Jul 21 21:04:39 192.168.1.3 kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: status: { DRDY } Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: failed command: READ FPDMA QUEUED Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: cmd 60/20:48:20:14:0c/00:00:84:00:00/40 tag 9 ncq dma 16384 in Jul 21 21:04:39 192.168.1.3 kernel: res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: status: { DRDY } Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: failed command: READ FPDMA QUEUED Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: cmd 60/10:50:70:87:64/00:00:7e:00:00/40 tag 10 ncq dma 8192 in Jul 21 21:04:39 192.168.1.3 kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: status: { DRDY } Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: failed command: READ FPDMA QUEUED Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: cmd 60/80:80:00:49:ab/00:00:88:00:00/40 tag 16 ncq dma 65536 in Jul 21 21:04:39 192.168.1.3 kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 21 21:04:39 192.168.1.3 kernel: ata15.00: status: { DRDY } Jul 21 21:04:39 192.168.1.3 kernel: ata15: hard resetting link Jul 21 21:04:40 192.168.1.3 kernel: mpt3sas_cm0: SAS host is non-operational !!!! Jul 21 21:04:40 192.168.1.3 kernel: mpt3sas_cm1: SAS host is non-operational !!!! Jul 21 21:04:41 192.168.1.3 kernel: mpt3sas_cm1: SAS host is non-operational !!!! Jul 21 21:04:41 192.168.1.3 kernel: mpt3sas_cm0: SAS host is non-operational !!!! Jul 21 21:04:42 192.168.1.3 kernel: ata15: failed to resume link (SControl FFFFFFFF) Jul 21 21:04:42 192.168.1.3 kernel: mpt3sas_cm1: SAS host is non-operational !!!! Jul 21 21:04:42 192.168.1.3 kernel: mpt3sas_cm0: SAS host is non-operational !!!! Jul 21 21:04:44 192.168.1.3 kernel: mpt3sas_cm1: SAS host is non-operational !!!! Jul 21 21:04:44 192.168.1.3 kernel: mpt3sas_cm0: SAS host is non-operational !!!! Jul 21 21:04:44 192.168.1.3 kernel: ata15: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF) Jul 21 21:04:45 192.168.1.3 kernel: mpt3sas_cm0: SAS host is non-operational !!!! Jul 21 21:04:45 192.168.1.3 kernel: mpt3sas_cm1: SAS host is non-operational !!!! Jul 21 21:04:46 192.168.1.3 kernel: mpt3sas_cm0: SAS host is non-operational !!!! Jul 21 21:04:46 192.168.1.3 kernel: mpt3sas_cm0: _base_fault_reset_work: Running mpt3sas_dead_ioc thread success !!!! Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449376 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449384 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449392 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449400 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449408 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449416 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449424 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449432 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449440 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449448 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449456 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449464 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449472 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449480 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449488 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449496 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449504 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449512 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449520 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449528 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449536 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449544 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449552 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449560 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449568 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449576 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449584 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449592 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449600 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449608 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449616 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=15798449624 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976912 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976920 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976928 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976936 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976944 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976952 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976960 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976968 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976976 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976984 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743976992 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977000 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977008 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977016 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977024 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977032 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977040 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977048 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977056 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977064 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977072 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977080 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977088 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977096 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977104 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977112 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977120 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977128 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977136 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977144 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977152 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=8743977160 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729824 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729832 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729840 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729848 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729856 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729864 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729872 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729880 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729888 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729896 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729904 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729912 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729920 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729928 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729936 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729944 Jul 21 21:04:46 192.168.1.3 kernel: md: disk10 read error, sector=13575729952 Jul 21 21:04:46 192.168.1.3 kernel: mpt3sas_cm1: SAS host is non-operational !!!! Jul 21 21:04:46 192.168.1.3 kernel: mpt3sas_cm1: _base_fault_reset_work: Running mpt3sas_dead_ioc thread success !!!! Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449376 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449384 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449392 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449400 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449408 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449416 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449424 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449432 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449440 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449448 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449456 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449464 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449472 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449480 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449488 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449496 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449504 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449512 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449520 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449528 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449536 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449544 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449552 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449560 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449568 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449576 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449584 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449592 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449600 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449608 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449616 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=15798449624 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188032 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188040 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188048 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188056 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188064 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188072 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188080 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188088 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188096 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188104 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188112 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188120 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188128 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188136 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188144 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188152 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188160 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188168 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188176 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188184 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188192 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188200 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188208 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188216 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188224 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188232 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188240 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188248 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188256 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188264 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188272 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=22087188280 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976912 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976920 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976928 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976936 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976944 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976952 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976960 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976968 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976976 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976984 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743976992 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743977000 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743977008 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743977016 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743977024 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743977032 Jul 21 21:04:46 192.168.1.3 kernel: md: disk12 read error, sector=8743977040 the disks themselves seem fine, so not really sure where to go from here

+1 Docker Swarm support

ah sorry about that, missed it whilst scrolling

hi @ich777i'm wondering if you can shed some light on how I can locate / fix this. I am using proxmox and unraid as a vm. I make use of vGPU unlock on proxmox, and I have passed a vGPU to unraid. we can see that here root@alexandria:~# nvidia-smi Thu Oct 31 08:17:45 2024 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 550.127.05 Driver Version: 550.127.05 CUDA Version: 12.4 | |-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 GRID V40-2B4 Off | 00000000:0B:00.0 Off | N/A | | N/A N/A P8 N/A / N/A | 1MiB / 2048MiB | 0% Prohibited | | | | N/A | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | No running processes found | +-----------------------------------------------------------------------------------------+ now when I do root@alexandria:~# nvidia-smi -q | grep "License" vGPU Software Licensed Product License Status : Unlicensed I wish to auth this, and i'm making use of https://git.collinwebdesigns.de/oscar.krause/fastapi-dls#unraid-guest which entails running https://git.collinwebdesigns.de/oscar.krause/fastapi-dls/-/commit/1fc5ac83789e8f27bb8f41ac445250b36ecb08b4 upon running that script im stuck at [>] Setting up gridd.conf cp: cannot stat '/etc/nvidia/gridd.conf.template': No such file or directory [!] Error configuring gridd.conf, did you install the drivers correctly? where would this file be located? or do you have any insight into what im doing wrongly?

bump and +1

+1 for vmtouch its possible

plugin: installing: file.activity.plg Executing hook script: pre_plugin_checks plugin: downloading: file.activity.plg ... done Executing hook script: pre_plugin_checks plugin: run failed: '/bin/bash' returned 2 Executing hook script: post_plugin_checks noticing this error, wlll back search now to see if others have it too

i've searched in the thread but can't really find it addressed too much but how do people go about mass updating their containers? i understand that the update stack button works and is great but its a bit cumbersome when you have to do that 30-40 times, rather than a single button press what solutions have people come to, to automate this? or is this something that could be added natively to the plugin? edit: seems watchtower is the solution that is posited in the previous page so i'll give that a shot

just checked it all again and seems to work now. so first i tried version: "3.9" services: tautulli: image: lscr.io/linuxserver/tautulli:latest container_name: tautulli env_file: - /boot/config/plugins/compose.manager/projects/test1/.env environment: - PUID=1000 - PGID=1000 - TZ=${TZ} ports: - 8181:8181 restart: unless-stopped networks: br0: ipv4_address: 192.168.1.133 volumes: - ${DOCKERDIR}/tautulli/config:/config networks: br0: external: true which results in WARN[0000] The "TZ" variable is not set. Defaulting to a blank string. WARN[0000] The "DOCKERDIR" variable is not set. Defaulting to a blank string. then i tried the same but env_file: - /boot/config/plugins/compose.manager/projects/.env which results in the same then i tried using .env: /boot/config/plugins/compose.manager/projects/.env [+] Running 1/1 ✔ Container tautulli Started 0.2s this worked without needing to declare the env_file. sorry about wasting your time, it seems to have always worked. Would it be possible to have a drop down menu or some kind of sticky location to the stack settings env file path? or maybe some kind of config file where we can store say multiple variables with an auto enabled: true / false flag?

take this one for example version: "3.9" services: tautulli: image: lscr.io/linuxserver/tautulli:latest container_name: tautulli env_file: - path: /boot/config/plugins/compose.manager/projects/.env service: tautulli environment: - PUID=1000 - PGID=1000 - TZ=${TZ} ports: - 8181:8181 restart: unless-stopped networks: br0: ipv4_address: 192.168.1.133 volumes: - ${DOCKERDIR}/tautulli/config:/config networks: br0: external: true you can delete the networking, its just using ipvlan but you can see we are declaring variables ${DOCKORDIR} and ${TZ} now define those values in your .env lets say TZ=UTC DOCKERDIR=/mnt/cache/appdata watch as you'll be unable to run, or rather when you run it you get an error stating that it cant find those variables so its defaulting to blank ones. This is because .env is special and will accept both environment variables and interpolate. declaring like above wont do that. if you wanted to get rid of the error you could on your docker host do `export DOCKERDIR="/mnt/cache/appdata"' but this would then store that in the unraid host which isn't desired. now if you just simply copy the .env from /boot/config/plugins/compose.manager/projects/.env and place it in /boot/config/plugins/compose.manager/projects/tautulli/.env (so it resides alongside the docker compose file) then everything will just work because of the things i mentioned.

there are effectively 2 options to have proper global .env support, its either have a file that sits at /boot/config/plugins/compose.manager/projects/.env and symlink it to each project folder, so for example /boot/config/plugins/compose.manager/projects/plex/.env would be a symlink of /boot/config/plugins/compose.manager/projects/.env or alternatively on every click of the docker up / docker down / stack update, it would take the values from /boot/config/plugins/compose.manager/projects/.env and append them to that specific projects .env file this would then allow for variable interpolation in the compose files, as most people desire

yes tested it just now and it doesn't work. its not the same. .env is special and env_file won't work, nor will -e flag it has to be in the same folder as the project

yeah unfortunately this implementation suffers with the exact same issues i mentioned previously in relation to interpolation. the only real solution to do global envs is to have one which sits outside and has a symlink to it in the project directory called .env the other solutions wont work. this is because docker has some special functions associated with .env rather than anything else, which allows it to pass interpolated variables as well as env variables.

thanks but can you elaborate more on this because i think it might not be exactly what i wanted now what i wanted was to put the envToUse in /boot/config/plugins/compose.manager/projects/envToUse and then that env file would subsequently be copied / replicated or symlinked to all the sub directories (i.e /boot/config/plugins/compose.manager/projects/plex/.env) the reason for this, is that the .env has special properties that otherwise addressing them via env_file declaring doesn't do. like my previous example with doing interpolation $DOCKORDIR your previous comment 'Is there a Github repo for this? I've modified some of this plugin locally to allow use of a "master" .env with multiple projects and I'd like to share it back.' seemed to hint at doing exactly this. if i declare an envToUse does it replicate across other projects?

hi im not sure if you are accepting feature requests but this would be useful for me. i've been down a rabbit hole of trying to do something like having a global .env file which i can use to do references and interpolation. it seems thats not possible if you have docker-compose files in directories and try to reference outside of it, even by hardcoding. i tried both env_file full/path and env_file ../.env and neither work. i'm wondering if we could have a global menu added and what that does, is upon boot, create, start and stop of any containers it will check the values in the global .env file and place them into each containers .env file. this would then allow easy referencing in compose, so for example instead of having to write out a long /mnt/ssd/cache/appdata/ you could reference that was $DOCKORDIR and just call $DOCKORDIR each time.

curious case post upgrading of parity drive never spinning down, appears to be some very small writing occuring and i cant out the cause of it

this 9+ year desired feature is still desired, nvme's have gotten so cheap now this would be a huge power up for our arrays.

it sounds like you are experiencing the same thing i am / did, if you check some of my posts i compare the speeds of SMB on windows server vs smb on unraid and its night and day different. In addition to that though, i've noticed what you have, as well as other things. For example when we had windows server installed, you could be at your windows desktop and just unzip from the remote desktop, as if it was locally stored on your hdd. with the linux implementation of smb, we cant do that. To get around that particular scenario I created a bash script to ssh into the unraid box, check what path i was on and find the file i wanted to unzip and execute 7z and then do perms cleanup and close. I imagine you'll need to do similarly and ssh into the other unraid and execute the move / copy that way. Others have done it via using midknight commander or that other docker one with rsync. Its unfortunately the nature of the beast and if you want that functionality we need windows server.

hahahah ok well thats a show stopper. i'm thinking though if its possible to execute scripts (does that work?) then we can fire off something something which starts a cron to invoke 'mover stop' after x period of time, and we use the maths to figure out how long it'd take to shift y amount of data (so in my case 1tb) my array performs on average 120 MB/s per drive. (assuming large sequential file transfer) (1 tb) / (120 (MB / s)) = 2.31 hours so i just need to do a daily mover, for 2 hours to shift like 800gb of data whenever its filled 85% and the script to stop it. that should in theory allow us to do it that way right?