Swarles

Do you happen to have this setting enabled? ---> "Move All from Cache-Yes shares when disk is above a certain percentage:" If yes, what is your percentage set to? And what is the percentage of storage taken up on your pool (cache_nvme)? I suspect this may be the source of the error. Do you have this setting enabled? --> "Move Now button follows plug-in filters:" If you do not, the behaviour you are seeing makes sense because (I believe, but correct me if I am wrong) when you run it manually it does not use the plugin mover settings. My suspicion is that this is the result of files attempting to be moved twice but I would like to confirm. I believe harmless, but still annoying.

Oh okay yep! This is my misunderstanding and in that case is definitely working as expected

Thanks for the heads up and update! When you say behave as I expected do you mean with regards to how I thought the manual increments setting only used increments if the parity check had been manually paused? Funnily enough I am doing a parity check right now because I had a power outage and I thought I would try do some testing. I'm on "Version: 2023.06.18" which I believe is the latest but I seem to get the standard behaviour. I updated the increments to test in real time. Here is what I did: START - 18:40, END - 18:45. Manual pause before start. It behaved as expected and paused the parity check at the end of the increment. START - 18:50, END - 18:55. Before increment start I manually resumed the parity check. Parity check was already running due to manual resume so no start at 18:50 but it still automatically paused at 18: 55. I thought maybe that I wasn't leaving enough time between the resume and start of the next parity check increment so manually resumed and waited ~35mins until the next increment start. START - 19:30, END - 19:35. It still paused the parity check at the end. This is no big issue obviously but just thought I would share my findings. I finally have a UPS now so hopefully I can do less of these hahaha!

I can also confirm that on a fresh install the mover does not run correctly I think due to the changes to using /tmp/Mover for log files. It appears the directory is not made to begin with. I tested the following before running the Mover for the first time on a fresh plugin install and then after running the mover got the second result. I'm not sure why this is the case because it should be made immediately on the first age_mover / mvlogger() run....hmmmmm. My first run also resulted in these systemlogs: The logs in /tmp/Mover on the first run were as follows: The second run I had the following systemlogs: And the following results in /tmp/Mover: TO NOTE: On first run the logs in /tmp/Mover appear to be missing logs at the beginning. On second run, it works fine. I did more testing and this is the case on every run after the system reboots. You'll notice that I broke it and didn't actually run it in test mode because using the exclude file types option I had spaces between them. I noticed this because I was going to add an extra variable to this (share name) for my settings-per-share update I am making but was worried that if they had a space it would break it. This could also be an issue for people using a skip files list, before script or after script on a share/folder path that has spaces so I have fixed it. I will push what I have done but you can feel free to reject, or change it EDIT: Created pull request for whitespace issue fix. Still no idea on the /tmp/Mover file/directory not being created issue.

I'm working on implementing this in Mover Tuning

Okay so I think I'm now getting a good grasp on understanding the logic of the Mover Tuning Plugin. I spent a good chunk of time learning how to read PHP and BASH and have just been following the trail of files/code on your github. The only thing left for me to read and understand is the loopcustomFIlelist() and loopArrayFilelist() functions in age_mover, which I will read tomorrow. Despite this, I think I have a good idea of how to approach implementing mover tunning functionality per share. It will be a lot of work especially for me who has never done this before, but I'm excited to give it a crack. I will create a fork of yours and work in that. The only thing I could not follow was IF mover.old is run (by manually pressing the default "move now" button) it sends a list of all the files on the pool to "/usr/local/bin/move" which has code in it I was not able to read or follow. Seemed like it was partially encrypted or something lol.

Yeah for sure! I'm trying to read up and understand how the Mover works, I know very little about linux/bash programming but in general given enough time can figure things out. Do you know of any good explanations or code where I can understand how the underlying Mover works in unraid? I'm currently viewing this script and I have checked out your fork for the mover tuning plugin, but that was difficult for me to follow at this point.

I was thinking about what might be an ideal way to set this up and believe that the "scheduler" Mover Tuning setting could be a universal setting for each share and then in "Shares>[specific share]>Mover Tuning" is where individual share mover settings could be overwritten. From my understanding, this only appeared after I installed the plugin? I don't know much about development, but might try to take a look to see if or how this would be possible. I will definitely take a look at this and try to create a script that meets my needs. Although I suspect there may be issues even if my script moves only the files types I want off the cache and onto the array, because then the universal mover will run and move them onto the array anyway? I'm not sure if I can disable it for a specific share? I may be able to set the share to cache only, and manually move files to the array but I'm not sure how this would impact the system that unraid uses to direct traffic to the correct drives using a single path (I forgot the name). Regardless, thanks for your help

Okay so I did some initial basic testing to get an idea of which route I would like to take but ideally would like to do more rigorous and quantitative testing soon. Using one sample data set, I tested 3 primary behaviours: PC to Cache (over 2.5Gbe smb) Cache to PC (over 2.5Gbe smb) Cache to Array The data set was 52.4 GB consisting of some tv series taken directly from Jellyfin with metadata (35.6 GB) as well as a variety of personal documents (word, pdf, programming, CAD files, etc : 16.7 GB). For simplicity I will call the 35.6GB portion “TV” and the 16.7 GP portion “Files”. I only performed each test once, logging time taken and average transfer speed, while manually observing CPU load and power consumption. RESULTS: In each case the compression resulted in slightly faster transfer speeds, but it should be noted in this case, the primary bottleneck for transfer speed was not the read or write speeds and instead the network so it is expected they should be similar. I observed that power consumption was similar perhaps +3W in general with compression turned on. I should have tested from the array to my PC and not the Cache to PC because again, this result is limited by the LAN and not the read/write speeds. Interestingly the decompression took a bit longer, I am not sure why this is the case. CPU load was similar as well as power consumption, maybe +3W on average. The results of compression start to show here where compression allows for faster transfer time onto the array for data that can be compressed. Interestingly I observed the CPU load with compression turned off to fluctuate a lot more and reached much higher loads and watts than previously seen in any test. Not sure if this is just a coincidence as I ran the test once, this was also only for part of the test where it then returned to expected figures. Again, in general compression turned on may only be increasing loads by ~3W. I have ordered an m.2 enclosure so I can perform these tests again but with a faster connection. I would also like to properly log CPU load and power consumption for a quantitative comparison, so will investigate ways to do this. In general, it would appear enabling compression is beneficial for both space savings and transfer speed (except for reads off cache, will need to investigate this) for a little bit of extra CPU load and power consumption. I’d recommend having compression turned on for anyone running zfs on their cache and array in new unraid.

+1 Did anyone figure out a workaround for this? Having a different Mover for a specific share?

+1 Anyone know if there is a work around to still achieve this?

Thanks for pointing this out, I did download it earlier but quickly dismissed it because I thought it applied the mover to ALL shares. Do you know if it is possible to apply different profiles to different shares? Or any other way I might be able to achieve that? I would love to be able to have all my other shares behave normally.

Hey so, it appears as though the logs stopped happening after the parity check completed. Next time I am running a parity check, I will observe the logs and if the error is happening I will go through the process of getting uou better log files. Thanks again

EDIT: TLDR - How can I apply different Mover features from the Mover Tuning Plugin on a per share basis? Hey everyone, This obviously isn't a standard request, but I am hoping someone might be able to help me come up with a good solution. I am wanting to have a media folder for my Jellyfin which is cache-->array so media files are stored on the array after being downloaded (but only when the mover runs). However, for simplicity in managing the media folder I would like to store metadata, artwork, etc in the folder with the media. This keeps it all together and also means I could in theory host another Jellyfin instance from a different computer, without having to download metadata again. BUT...I don't want the array to spin up every time a user accesses the server simply to provide artwork. It would also load much faster on my cache. Ideally I would find some kind of solution where the mover does not move certain files (e.g. .jpeg, .svg, .nfo, .mp3) in this particular share from the cache to the array. I do understand I could simply not store artwork in the media folder, which I will do if there is no solution for my outlined problem. The primary reason I want to try to achieve it the way I suggested is because I use a theme song plugin for Jellyfin and this must store the .mp3 in the media folder for Jellyfin to find it. This would result in the behaviour of the array being started every time a user automatically loads a theme song, which is not ideal. I don't want the array to start unless a video file is being loaded. BONUS QUESTION: Is it possible to get Mover behaviour (on a specific share) that only moves files that are X days old? This could allow the cache to serve recently downloaded content (more likely to be accessed) faster and without starting up the array. Thank you for taking the time to read through this

Unraid: 6.12.0-rc8 Plugin: 2023.05.07 If it is any help, I don't recall seeing this log earlier in the day which leads me to believe it only started after I manually resumed the parity check (outside of a scheduled increment). This may just be a coincidence though. I tried setting "Use increments for manual Parity Check:" to "No" and the log still appeared.

Oh ok, upon re-reading the explanation for the setting I can see how I misinterpreted it. I thought that it only scheduled a manual parity check to continue in increments if two conditions were met: 1) a manual parity check had been started, 2) the manual parity check got paused. But I can now see this was only an explanation to demonstrate that the parity check would continue in scheduled increments and not a condition that needed to be met. Perhaps I could suggest an alternate description that may negate a misunderstanding like mine: "With this option set to Yes; if you manually start a Parity Check from the Main page, the check will continue until the end of the next scheduled increment, and then use increments until the Parity Check is completed. Otherwise, if the Parity Check is manually paused, it will be resumed at the beginning of the next scheduled increment." Feel free to use that if you want to change it or not if you think it'll just be more confusing or too long Do you think it would be possible to implement the behaviour that I initially thought it would be without having to toggle the setting during a parity check? Without knowing how plugins, or the scheduler, or parity checks work, my initial thought would be to have some kind of flag parameter that is changed if a manual parity check is at any point manually paused. Then if this flag is set true, every time a scheduled increment starts or ends, it checks the flag and starts or pauses the parity check if it is true. Otherwise, if the manual parity check is then manually resumed, it sets the flag false. I'm not sure how difficult it would be to achieve something like this but I think it would be a very useful feature where you can run the parity check for as long as possible until you need better IO throughput, and then if you do manually pause it, it continues the check during scheduled increments until completion or until you manually resume it again. This way if you start a manual check at night with the intention of letting it run until midday where you might need to pause it, it doesn't automatically pause at the end of the first increment. I do see how this could be annoying for someone who just wants the manual check to be incremented, they could still achieve that result by starting the check and then immediately pausing it. I'd be happy to help in anyway I can if possible. SORRY to bombard you with all of this, I just have one more question. I noticed my logs were getting spammed with this every 6 minutes: Jun 15 00:12:35 unraid crond[1121]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Jun 15 00:18:43 unraid crond[1121]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Jun 15 00:24:33 unraid crond[1121]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null Any idea why this is the case? Thank you so much!

Hey there, I installed the Parity Check Tuning plugin last night and enabled the increments for a manual check option. My intention was to run a manual parity check for as long as I can until I need to pause it and then having it complete in increments in scheduled time. However, what I observed today is that despite not manually pausing the check at any point, it automatically paused it outside of the scheduled increment as it ended. Jun 14 07:30:01 unraid Parity Check Tuning: Paused: Manual Correcting Parity-Check Jun 14 07:30:06 unraid kernel: mdcmd (37): nocheck pause Jun 14 07:30: 06 unraid kernel: Jun 14 07:30:06 unraid kernel: m: recovery thread: exit status: -4 Jun 14 07:30:11 unraid Parity Check Tuning: Send notification: Paused: Manual Correcting Parity-Check (38.7% completed) Jun 14 07:30:11 unraid Parity Check Tuning: ... but suppressed as system notifications do not appear to be enabled For reference I am running 6.12.0-rc8. Not a big issue, but thought I’d post in case it is a bug. Although I may have just done something wrong. My settings are attached.

Thank you for the feedback, both of you, I really appreciate it. Yeah I think this approach makes sense for testing the cache pool. I may need to find a way to add an additional m.2 to my system as I don’t own any sata ssd. This is good to know thanks. Although, the memory dashboard reports that “zfs” is always using 30-50% (usually whatever I have left free). Overall it is my hope that by enabling compression on the drives it saves space where it can (for not that much more power increase) and quickly skips files that would be ineffective to do so. I’ll see what I can do to get some conclusive results. Thanks

While I do have some older media, it’s certainly not enough to warrant trying to compress it. It’s not that I want to compress this media, it’s more that I just want to set and forget “compression: on” for each of my zfs drives in my configuration (which is all of them at this point). This reddit post combined with other research has lead me to believe that lz4 compression (from my understanding Unraid zfs is using lz4 by default) is pretty quick to stop attempting to compress an already compressed file. My thought process is that performance and power impact is probably negligible in this case as it skips compression on most of these files. But I’m also not sure if this will actually be the case and figure I should test it.

@JorgeB Okay yeah I was thinking that would probably be the simplest way to test it. I'm wondering what would be the best location to copy the data from? I definitely cannot saturate the write/read speeds of the server as my network is only 1gbe currently. If I connect ethernet directly to my server I can achieve 2.5gbe speeds with a USB 2.5gbe adapter on a personal PC, I suppose this is the best I can do. Or perhaps I am over thinking it and I only need to move data between the cache pool and the array? By ARC size you are referring to "adaptive replacement cache"? If this is the case, my memory is only 16GB but I will probably try collate sample data of 30GB+. I'm also wondering the impact on the CPU for decompression for each user that may be using Jellyfin, as there is a lot of files being accessed in this case (media, posters, audio, subtitles, bif, etc). Do you think the best way to test this would be to clone a media share and additional jellyfin docker; One share with compression enabled and one with it disabled? Thank you

TLDR: How can I create a repeatable test for read/write performance on a zfs file system (6.12-RC8) to compare the results when compression is enabled and disabled on a disk? Intending to test the array and a mirrored cache pool. Hey everyone, So I recently put together my low-power unraid build and ultimately used 6.12.0-rc8 to create a zfs array and a mirrored cache pool also using zfs. I'm struggling to decide whether or not I turn on compression for all my drives, and want to compare it. In general I want compression for extra space and transfer speed benefits, but before I commit and move data onto the server with compression I want to see if this will have significant impact on my power consumption. My server will host movies (hevc) as well as system backups, documents, photos, etc. I know that for already compressed data having compression on is pointless, but from research it seems that lz4 compression is pretty quick to give up on already compressed data so it might be a non-issue. Ideally what I want to achieve is a test where I can iterate a file read/write process for compressible and non-compressible data on both the cache and the array. This way the test is easily repeatable and I can simultaneously monitor CPU load as well as my power meter to determine the impact on power draw. I tried using the DiskSpeed docker with the intention to see if there was a difference between compression enabled and disabled, but it appears the tests do not work on zfs. I'm also not sure what type of data it writes and if it would be relevant for my purposes. Currently my system idles at about 10W with my dockers running and the disks spun down. I reach about 21W when both disks are spinning (no read/writes). If on-the-fly compression and decompression adds only a couple extra watts then it will be worth enabling it for the storage and read/write benefits. Appreciate any help, thanks!

Ohhh man this makes so much sense! I probably could have figured that out if I thought about how HDD actually work a bit more. Thanks for the answer!

I tried to find an answer to this and it seems to be general knowledge that it happens...but why does the read/write speed decrease as a preclear or parity check progresses through the disk. I knew this would happen ahead of time because I have rad other peoples experiences, but I'm just wondering why. When doing my preclear on 2x 16TB Ironwolf Pro both the zeroing and post read took about 21 hours each. They both started with write/read speeds of about 270MB/s and by the end were going at ~180MB/s for an average of approximately 205MB/s for each stage. Unfortunately when I added them to the new array configuration and started it, I forgot to tick the "parity already valid checkbox" and it automatically started a sync. After that, I decided to make the config again and check the box. But because I could no longer verify the signature on the precleared drives I was paranoid that parity may not be correct so I started a check anyway. Again, the read speeds started at about 260MB/s and now at 75% complete, it is going at 185MB/s. I expect it will creep down further over the next 25%. Why is this consistently the case?

Does anyone know how to get this working for a ZFS filesystem? I believe the reason this test does not work for me is because I am using a ZFS file system for my cache pool and single drive ZFS for the array. I really want to benchmark the speeds of my drives, with and without compression turned on to compare speed, CPU load, and power consumption. I'm not sure if compression turned on will even make a difference for the way these tests run but for now this feels like the simplest way to benchmark the effects of compression being enabled. Would be very grateful to get some feedback on how this might be possible. Thank you

Does anyone know of any energy efficient UPS? Less than 5W wasted energy when the battery is full?