August 13, 20178 yr I'm not sure when it happened, but somewhere along the way the "Mover" function went missing. I'm running 6.3.5 and it is no longer on my main tab or under scheduler. No amount of Google-Fu has helped. I'm open to any ideas.
August 13, 20178 yr Community Expert Do you have an assigned cache device? If yes diagnostics may show some clues.
August 13, 20178 yr Author I do have 2 cache drives (1 for parity). I've dug through diagnostics, but nothing is jumping out at me...but I'll post it here for smarter minds to gander. tower-diagnostics-20170813-1436.zip
August 13, 20178 yr Best for @johnnie.black to answer: Aug 12 14:22:40 Tower emhttp: shcmd (82): mkdir -p /mnt/cache Aug 12 14:22:40 Tower emhttp: mount error: Too many misplaced devices: 1 Aug 12 14:22:40 Tower emhttp: shcmd (83): umount /mnt/cache |& logger
August 13, 20178 yr Community Expert I saw that but after that he reassigned the missing device and the pool mounted, so no reason for the mover to not work then.
August 13, 20178 yr Sorry. Still learning your Kung Fu. I'm just a grasshopper. But, here's why mover isn't appearing. /mnt/user0 never got mounted, even though the cache drive did. I suspect that a reboot might fix it all up, since FCP isn't complaining about the cache being unmountable. Aug 12 14:31:46 Tower emhttp: shcmd (860): mkdir -p /mnt/cache Aug 12 14:31:46 Tower emhttp: shcmd (861): set -o pipefail ; mount -t btrfs -o noatime,nodiratime -U 06e1ae7a-7152-48cf-8d36-0ce0eba6224b /mnt/cache |& logger Aug 12 14:31:46 Tower kernel: BTRFS info (device sdh1): disk space caching is enabled Aug 12 14:31:46 Tower kernel: BTRFS info (device sdh1): has skinny extents Aug 12 14:31:46 Tower kernel: BTRFS info (device sdh1): detected SSD devices, enabling SSD mode Aug 12 14:31:46 Tower emhttp: shcmd (862): sync Aug 12 14:31:46 Tower emhttp: shcmd (863): mkdir /mnt/user Aug 12 14:31:46 Tower emhttp: shcmd (864): /usr/local/sbin/shfs /mnt/user -disks 30 -o noatime,big_writes,allow_other -o remember=330 |& logger Aug 12 14:31:46 Tower emhttp: shcmd (865): rm -f /boot/config/plugins/dynamix/mover.cron Aug 12 14:31:46 Tower emhttp: shcmd (866): /usr/local/sbin/update_cron &> /dev/null Edited August 13, 20178 yr by Squid
August 14, 20178 yr Author 5 hours ago, Squid said: Best for @johnnie.black to answer: Aug 12 14:22:40 Tower emhttp: shcmd (82): mkdir -p /mnt/cache Aug 12 14:22:40 Tower emhttp: mount error: Too many misplaced devices: 1 Aug 12 14:22:40 Tower emhttp: shcmd (83): umount /mnt/cache |& logger That was me mucking about removing cache parity, without remembering to reduce drive number, in an attempt to see if I could get mover back...didn't work.
August 14, 20178 yr Author 21 hours ago, Squid said: Sorry. Still learning your Kung Fu. I'm just a grasshopper. But, here's why mover isn't appearing. /mnt/user0 never got mounted, even though the cache drive did. I suspect that a reboot might fix it all up, since FCP isn't complaining about the cache being unmountable. Aug 12 14:31:46 Tower emhttp: shcmd (860): mkdir -p /mnt/cache Aug 12 14:31:46 Tower emhttp: shcmd (861): set -o pipefail ; mount -t btrfs -o noatime,nodiratime -U 06e1ae7a-7152-48cf-8d36-0ce0eba6224b /mnt/cache |& logger Aug 12 14:31:46 Tower kernel: BTRFS info (device sdh1): disk space caching is enabled Aug 12 14:31:46 Tower kernel: BTRFS info (device sdh1): has skinny extents Aug 12 14:31:46 Tower kernel: BTRFS info (device sdh1): detected SSD devices, enabling SSD mode Aug 12 14:31:46 Tower emhttp: shcmd (862): sync Aug 12 14:31:46 Tower emhttp: shcmd (863): mkdir /mnt/user Aug 12 14:31:46 Tower emhttp: shcmd (864): /usr/local/sbin/shfs /mnt/user -disks 30 -o noatime,big_writes,allow_other -o remember=330 |& logger Aug 12 14:31:46 Tower emhttp: shcmd (865): rm -f /boot/config/plugins/dynamix/mover.cron Aug 12 14:31:46 Tower emhttp: shcmd (866): /usr/local/sbin/update_cron &> /dev/null Well, I rebooted, but still no mover options anywhere. Even when I invoke it with cli, nothing is happening. Here's my latest diagnostic, after fresh boot. tower-diagnostics-20170814-1402.zip
August 14, 20178 yr Go to Settings -> Global Share Settings -> Cache settings and change "Use cache disk" to "Yes".
August 14, 20178 yr Author If I've read what you wrote correctly, Squid...there should be a user0 listed under mnt. I honestly don't remember ever seeing that user. Here is what is what is under mnt.
August 14, 20178 yr Just now, dojesus said: If I've read what you wrote correctly, Squid...there should be a user0 listed under mnt. I honestly don't remember ever seeing that user. You don't have /mnt/user0 because your use cache setting is set to "No", change it to "Yes".
August 14, 20178 yr 48 minutes ago, bonienl said: You don't have /mnt/user0 because your use cache setting is set to "No", change it to "Yes". I missed that one Always something simple.
August 14, 20178 yr Community Expert 16 minutes ago, Squid said: I missed that one Always something simple. Join the club
August 14, 20178 yr Author If I' 1 hour ago, bonienl said: You don't have /mnt/user0 because your use cache setting is set to "No", change it to "Yes". Yup, that was it. Thank you SO much!. New issue....now all my dockers (Plex, Sonarr, etc.) are now no longer operating correctly. No WebGUI's working. Do I need to reinstall all my appdata stuff?
August 14, 20178 yr 1 minute ago, dojesus said: New issue....now all my dockers (Plex, Sonarr, etc.) are now no longer operating correctly. No WebGUI's working. Do I need to reinstall all my appdata stuff? I'm assuming that the apps are appearing within the docker tab. Wouldn't be a bad idea to post up the following: A screenshot of the docker tab showing the apps and the various mountings, etc. The log's from the a container. Another set of diagnostics. But, push comes to shove, with everything that happened on the cache drive, it really wouldn't surprise me if you're going to be forced to start the appdata over again from scratch (unless you've got a backup). But lets see where the above takes us.
August 14, 20178 yr Author Thanks for the help Squid, Bonienl and johnnie. I can post the screenshots and log for sonarr now. I'll have to post the new diagnostics later, as I'm off to work. sonarr.txt
August 14, 20178 yr Quick scan before the diagnostics / docker screen shot shows the following: [Fatal] ConsoleApp: EPIC FAIL! Probably not much comfort, but if you're going to fail, at least go all out and do it EPICally! But it might be related to [v2.0.0.4949] System.Data.SQLite.SQLiteException (0x80004005): database or disk is full The diagnostics would tell me.
August 15, 20178 yr Author Yeah, my whole understanding of my loss of cache has definitely felt like an epic fail...lol. Well, it tried a reinstall of Sonarr, and that fixed it....except it lost all my data and I have to rebuild my shows list. Oh well... I think I'm good from here. Thanks for all your help! BTW, I quickly ran out of space when the mover started working and I'm thinking of dropping the parity on my cache and going jbod, until I can afford some larger drives. Any thoughts or suggestions on that?
August 15, 20178 yr 26 minutes ago, dojesus said: I quickly ran out of space when the mover started working If you mean your cache drive ran out of space, then you've got some shares set to use cache:prefer. That setting pulls files from the array and drops them onto the cache drive. Set them to either No or Yes. IMHO, the only shares that should be Prefer are the appdata share (or set to Only), and downloads share. Edited August 15, 20178 yr by Squid
August 15, 20178 yr Author Yes, the cache ran out of space as appdata was set to only, however lots of old dockers (previous versions of Plex being the worst offender) were somehow still present eating up over 150GB of cache space. I cleaned them out, though I thought uninstalling the docker would have done that. Gonna have to keep an eye on that in the future.
August 15, 20178 yr 6 minutes ago, dojesus said: Yes, the cache ran out of space as appdata was set to only, however lots of old dockers (previous versions of Plex being the worst offender) were somehow still present eating up over 150GB of cache space. I cleaned them out, though I thought uninstalling the docker would have done that. Gonna have to keep an eye on that in the future. appdata should have setting cache only, that is correct. Don't know how big your collection is, 150GB doesn't sound right for plex. For comparison my plex data is about 5GB for 2000 movies + 1000 episodes.
August 15, 20178 yr Author I'm not sure how SSD's differ from HDD's in allocation, but the combined metadata of Plex, for me is almost 150GB, at least when Windows is looking at it. Since I'm stuck with 256GB SSD's, do you think a JBOD cache would be a better way to go?
August 15, 20178 yr 9 minutes ago, dojesus said: I'm not sure how SSD's differ from HDD's in allocation, but the combined metadata of Plex, for me is almost 150GB, at least when Windows is looking at it. That is not a case of allocation for SSD vs HDD, it is just a case of Windows assuming an incorrect allocation size over the network... 1MiB IIRC.
August 15, 20178 yr Windows isn't calculating the disk size properly. Below my Plex folder according to Windows and Total Commander.
Archived
This topic is now archived and is closed to further replies.