theuema

I ran into an issue recently, when trying to mount a SSD cached share on my Enigma2 Linux receiver permanently, to store my recordings directly onto my unraid server! I use fstab to mount the share (just added nfsvers=4 while investigating the error; not needed): 192.168.178.60:/mnt/user/recordings /media/recordings nfs _netdev,nfsvers=4,rw 0 0 It works till the mover moves the recordings from SSD cache pool into the array. After that i get the following errors on the fstab-mounted nfs share on my receiver: root@dreambox:~$ mount -t nfs 192.168.178.60:/mnt/user/recordings /media/recordings mount.nfs: Stale file handle root@dreambox:~$ rpcinfo -p 192.168.178.60 program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 34064 status 100024 1 tcp 47303 status 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 udp 49947 nlockmgr 100021 3 udp 49947 nlockmgr 100021 4 udp 49947 nlockmgr 100021 1 tcp 41379 nlockmgr 100021 3 tcp 41379 nlockmgr 100021 4 tcp 41379 nlockmgr 100005 1 udp 60889 mountd 100005 1 tcp 50843 mountd 100005 2 udp 33420 mountd 100005 2 tcp 55269 mountd 100005 3 udp 59744 mountd 100005 3 tcp 55475 mountd root@dreambox:~$ showmount -e 192.168.178.60 Export list for 192.168.178.60: /mnt/user/media * /mnt/user/recordings * root@dreambox:~$ ls -l /media/recordings ls: /media/recordings: Stale file handle root@dreambox:~$ showmount -a clnt_create: RPC: Program not registered root@dreambox:/media$ cat /proc/mounts | grep nfs nfsd /proc/fs/nfsd nfsd rw,relatime 0 0 192.168.178.60:/mnt/user/recordings /media/recordings nfs4 rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.178.70,local_lock=none,addr=192.168.178.60 0 0 AFAIK, this can be solved by un-exporting and re-exporting the relevant exports on the server: exportfs -ua exportfs -a and afterwards manually mounting the nfs share on the receiver, mount -t nfs ... But, idk how to schedule this? E.g.: I have several docker containers running, but the mover moves, although I never put them down. I set the daily mover schedule to 05:45, but realized that the other day the mover moved my recordings somewhere around 17:00 (maybe even 17:45 - but there is no AM/PM setting? Therefore, i think this is just a coincidence.). So i can't schedule a cron job for manual mounting my recordings share -> NFS-Shares that must be permanently mounted can not be cached! When deactivating the SSD-Cache and directly using the HDD within my Array it seems to work. Would appreciate the cached solution though.

Hi, I do encounter quite unsatisfying behavior in terms of volatile speeds when copying or moving files from one share to another using rsync. Please view my attached screen recording. In this case, i was copying a 16Gig, or so, file between shares. The source share is located on the same physical HDD than the destination share. Speeds range from <1 MB/s to >200MB/s, always going up and down, like some super-fast cache gets filled up and the HDD can not handle all the incoming data. Does anybody have a better explanation or encounters the same when copying via. ssh/rsync? Screen Recording 2023-02-03 at 18.31.27.mov

After reading this TRaSH Guide (again), I am not very positive that there is a way to achieve a useful location for .nzbget/ that avoids atomic moves other than directly in my media-dl/ (cache_ssd 'Yes' enabled share), like this: - mnt/user/media-dl/ -- .nzbget/ ---- intermediate/ ---- complete/ -- movies/ ---- HD.movies/ -- shows/ ---- TV.shows/ So, I am considering changing the mover script the following way and I hope not to break important stuff here^^ # Check for objects to move from pools to array for POOL in /boot/config/pools/*.cfg ; do for SHAREPATH in /mnt/$(basename "$POOL" .cfg)/*/ ; do SHARE=$(basename "$SHAREPATH") if grep -qs 'shareUseCache="yes"' "/boot/config/shares/${SHARE}.cfg" ; then find "${SHAREPATH%/}" -not \( -path "*.nzbget/*" -prune \) -not \( -path "*.nzbget" -prune \) -depth | /usr/local/sbin/move -d $LOGLEVEL fi done done From testing the initial find command i got the following: root@UNRAID:/mnt/user# find media-dl/ -depth media-dl/.nzbget/test.txt media-dl/.nzbget media-dl/movies/HD.movies/Movie.1.mkv media-dl/movies/HD.movies media-dl/movies media-dl/shows/TV.shows/Show1/S01/Show1.S01E01.mkv media-dl/shows/TV.shows/ media-dl/shows media-dl/.DS_Store media-dl/._.DS_Store media-dl/ Using the new command gives this: media-dl/movies/HD.movies/Movie.1.mkv media-dl/movies/HD.movies media-dl/movies media-dl/shows/TV.shows/Show1/S01/Show1.S01E01.mkv media-dl/shows/TV.shows/ media-dl/shows media-dl/.DS_Store media-dl/._.DS_Store media-dl/ I am not planning to do anything on the "# Check for objects to move from array to pools"-find command some lines below, I hope I don't forget anything here. Please let me know what you think about this solution.

I am new to Unraid, loving it so far, but have quite some trouble now figuring out the best way of caching my media downloads. Share for media downloads (NZBGet) is created from the WebUI, called media-dl. Use cache pool: Yes, so i want to have the mover handling those files on a daily basis. NZBGet uses a folder for intermediate or complete downloads, therefore I set up the following folder structure yesterday: - mnt/user/media-dl/ -- .nzbget/ -- movies/ -- shows/ thinking that Mover will not move directories which begin with a '.' character, but: "Mover will not move any top-level directories which begin with a '.' character" In terms of mounting volumes to my docker container I am not quite sure how to handle this: If I create a directory /mnt/cache_ssd/.nzbget/ it is linked to /mnt/user/.nzbget/ touch /mnt/cache_ssd/.nzbget/test.txt creates the file visible in /mnt/user/.nzbget/ too, since it is essentially a hidden share (? Can't see it in the shares section in WebUI) touch /mnt/user/.nzbget/test2.txt creates the file only visible in /mnt/user/.nzbget/, not in /mnt/cache_ssd/.nzbget/ I believe this is wanted behaviour, because one would need to set 'prefer' or 'Yes' to the share ".nzbget" to actually store a file created in /mnt/user/.nzbget to the cache_ssd pool. So, this is where I'm not sure what is the most performant way to solve this in terms of mounting my docker volumes for NZBGet: I need to have /mnt/user/media-dl/ mounted; everything in media-dl/ is not top-level anymore and is moved, like right now, media-dl/.nzbget/ is moved; -> I need to mount /mnt/user/media-dl/ to have NZBGet categories (or sonarr/radarr) moving it to the appropriate folders (e.g. shows/rome/S01/...) I need to put .nzbget/ to /mnt/cache_ssd/.nzbget/ to prevent the mover seeing it; /mnt/user/.nzbget/ is created, but I can't mount this folder, since it is stored anywhere, but not on the cache_ssd/, where I want the files to be extracted and processed; -> I need to specifically mount /mnt/cache_ssd/.nzbget/ and configure NZBGet accordingly to have tmp, complete and intermediate files there, not seen by the mover. Then it looks like this (remember: media-dl is a cache_ssd 'Yes' enabled share): - mnt/cache_ssd/.nzbget -> mounted to NZBGet docker /nzbget/ - mnt/user/.nzbget -> link directory; essentially a 'hidden share'; this path cannot be used, since it is not configurable in the shares WebUI - mnt/user/media-dl/ -> mounted to NZBGet docker /media-dl/ -- movies/ -- shows/ But here, i have some questions: If I mount it this way, even though both volumes mounted reside on the same physical ssd drive, pool and filesystem (cache_ssd), what would happen if the files are moved from /mnt/cache_ssd/.nzbget/intermediate/ to /mnt/user/media-dl/movies/HD/ ? Does the system actually unneccesarily move the file and not hardlink (or whatever it is called in xfs?) the file in the filesystem? If yes, what is the better solution here?