15 minutes ago, bbbilly05 said:

Confirming that share is cache > array when mover runs.  It happens across all shares, not just that one - but I'd grabbed it as an example.

 

Please open issue in github include log and debug.

Strange I can't really reproduce it, I have many cache yes shares, all ok. 

Seems no other people has it.. 

1 hour ago, Masterwishx said:

 

Please open issue in github include log and debug.

Strange I can't really reproduce it, I have many cache yes shares, all ok. 

Seems no other people has it.. 

 

I am seeing the same behavior

 

Mar  5 11:31:55 falcon move: ----------------------------------------------------------------- Global settings ---------------------------------------------------------------
Mar  5 11:31:55 falcon move: Using global moving threshold: 80 %
Mar  5 11:31:55 falcon move: Using global freeing threshold: 40 %
--------------------------------------------
Mar  5 11:31:55 falcon move: Primary storage: cache_download - size: 239GiB - used:  16 % (37GiB)
Mar  5 11:31:55 falcon move: Secondary storage: user0
Mar  5 11:31:55 falcon move: Share Information: Name: media - Path: /mnt/*/media
Mar  5 11:31:55 falcon move: Moving threshold: 99% (237GiB) ; Freeing threshold: 0% (0B)
Mar  5 11:31:55 falcon move: Mover action: user0->cache_download (cache:prefer). Pool is above freeing threshold percentage and below priming threshold percentage: 0% <  16% < 99%.
Mar  5 11:31:55 falcon move: => Skipping

 

Created https://github.com/masterwishx/ca.mover.tuning/issues/25

8 minutes ago, tehg said:

 

I am seeing the same behavior

 

Mar  5 11:31:55 falcon move: ----------------------------------------------------------------- Global settings ---------------------------------------------------------------
Mar  5 11:31:55 falcon move: Using global moving threshold: 80 %
Mar  5 11:31:55 falcon move: Using global freeing threshold: 40 %
--------------------------------------------
Mar  5 11:31:55 falcon move: Primary storage: cache_download - size: 239GiB - used:  16 % (37GiB)
Mar  5 11:31:55 falcon move: Secondary storage: user0
Mar  5 11:31:55 falcon move: Share Information: Name: media - Path: /mnt/*/media
Mar  5 11:31:55 falcon move: Moving threshold: 99% (237GiB) ; Freeing threshold: 0% (0B)
Mar  5 11:31:55 falcon move: Mover action: user0->cache_download (cache:prefer). Pool is above freeing threshold percentage and below priming threshold percentage: 0% <  16% < 99%.
Mar  5 11:31:55 falcon move: => Skipping

 

Created https://github.com/masterwishx/ca.mover.tuning/issues/25

This is not same it's fix for cache prefer for not to move data befor 99%

Maybe I will find more fine solution for this

10 minutes ago, tehg said:

I am seeing the same behavior

Do you want to move data in cache prefer befor 99%?

@Masterwishx I think this data might be useful for the current issue:

 

I have four shares:

-  2x are cache:prefer, 2x are cache:yes

 

I had an override originally set for the 2x cache:prefer that set mover tuning to 95% and 0% thresholds to avoid the original issue with cache:prefer shares.  With your new fix, this shouldn't be a problem as I think you force all cache:prefer shares to 98% and 0%. 

 

So I removed the override and indeed cache:prefer looks good.

 

With no per-share overrides setup, the log looks something like this:

Quote

Mar  5 12:24:50 Dammerung move: ----------------------------------------------------------------- Global settings ---------------------------------------------------------------
Mar  5 12:24:50 Dammerung move: Using global moving threshold: 65 %
Mar  5 12:24:50 Dammerung move: Using global freeing threshold: 25 %
Mar  5 12:24:50 Dammerung move: Age: 15
Mar  5 12:24:50 Dammerung move: After script: /tmp/user.scripts/tmpScripts/mover_post/script
Mar  5 12:24:50 Dammerung move: Before script: /tmp/user.scripts/tmpScripts/empty_recycle_bin/script
Mar  5 12:24:50 Dammerung move: Clean Folders: yes
Mar  5 12:24:50 Dammerung move: CTIME: yes
Mar  5 12:24:50 Dammerung move: Test Mode: yes
Mar  5 12:24:50 Dammerung move: Notify: no
Mar  5 12:24:50 Dammerung move: Debug Logging: no
Mar  5 12:24:50 Dammerung move: Validate Filenames: yes
Mar  5 12:24:50 Dammerung move: Launching before script: /tmp/user.scripts/tmpScripts/empty_recycle_bin/script
Mar  5 12:24:50 Dammerung move: Recycle bin directory does not exist: /mnt/user/scratchpad/.Recycle.Bin
Mar  5 12:24:50 Dammerung move: Before script finished
Mar  5 12:24:50 Dammerung move: ***************************************************************** FILTERING FILES ***************************************************************

<snip>

Mar  5 12:24:52 Dammerung move: ----------------------------------------------------------- Processing [plex_lib] share ---------------------------------------------------------
Mar  5 12:24:52 Dammerung move: Primary storage: cache - size: 932GiB - used:  86 % (791GiB)
Mar  5 12:24:52 Dammerung move: Secondary storage: user0
Mar  5 12:24:52 Dammerung move: Share Information: Name: plex_lib - Path: /mnt/cache/plex_lib
Mar  5 12:24:52 Dammerung move: Moving threshold: 99% (923GiB) ; Freeing threshold: 0% (0B)
Mar  5 12:24:52 Dammerung move: Mover action: cache->user0 (cache:yes). Pool is below moving threshold percentage:  86% < 99%.
Mar  5 12:24:52 Dammerung move: => Skipping

The cache:yes share moving threshold is set to 99%, but my global settings are set to 65%.

 

Now If I add a single override (unrelated to the [plex_lib] share, the global setting seems to apply again:

 

Quote

Mar  5 12:28:12 Dammerung move: ------------------------------------------------------------- Processing [data] share -----------------------------------------------------------
Mar  5 12:28:12 Dammerung move: Settings override:
Mar  5 12:28:12 Dammerung move: ------------------
Mar  5 12:28:12 Dammerung move: Using share moving threshold: 90 %
Mar  5 12:28:12 Dammerung move: Using share freeing threshold: 0 %
Mar  5 12:28:12 Dammerung move: Age: no = 0 ; daysold:
Mar  5 12:28:12 Dammerung move: ------------------------------------------------------------------------
Mar  5 12:28:12 Dammerung move: Primary storage: cache - size: 932GiB - used:  86 % (791GiB)
Mar  5 12:28:12 Dammerung move: Secondary storage: user0
Mar  5 12:28:12 Dammerung move: Share Information: Name: data - Path: /mnt/*/data
Mar  5 12:28:12 Dammerung move: Moving threshold: 99% (923GiB) ; Freeing threshold: 0% (0B)
Mar  5 12:28:12 Dammerung move: Mover action: user0->cache (cache:prefer). Pool is above freeing threshold percentage and below priming threshold percentage: 0% <  86% < 99%.
Mar  5 12:28:12 Dammerung move: => Skipping

<snip>
Mar  5 12:28:12 Dammerung move: ------------------------------------------------------------- Processing [isos] share -----------------------------------------------------------
Mar  5 12:28:12 Dammerung move: Restore global settings
Mar  5 12:28:12 Dammerung move: -----------------------
Mar  5 12:28:12 Dammerung move: Using global moving threshold: 65 %
Mar  5 12:28:12 Dammerung move: Using global freeing threshold: 25 %
Mar  5 12:28:12 Dammerung move: Age: 15
Mar  5 12:28:12 Dammerung move: After script: /tmp/user.scripts/tmpScripts/mover_post/script
Mar  5 12:28:12 Dammerung move: Before script: /tmp/user.scripts/tmpScripts/empty_recycle_bin/script
Mar  5 12:28:12 Dammerung move: Clean Folders: yes
Mar  5 12:28:12 Dammerung move: CTIME: yes
Mar  5 12:28:12 Dammerung move: Test Mode: yes
Mar  5 12:28:12 Dammerung move: Notify: no
Mar  5 12:28:12 Dammerung move: Debug Logging: no
Mar  5 12:28:12 Dammerung move: Validate Filenames: yes
Mar  5 12:28:12 Dammerung move: ------------------------------------------------------------------------
Mar  5 12:28:12 Dammerung move: Primary storage: cache - size: 932GiB - used:  86 % (791GiB)
Mar  5 12:28:12 Dammerung move: Secondary storage: user0
Mar  5 12:28:12 Dammerung move: Share Information: Name: isos - Path: /mnt/cache/isos
Mar  5 12:28:12 Dammerung move: Moving threshold: 65% (606GiB) ; Freeing threshold: 25% (233GiB)
Mar  5 12:28:12 Dammerung move: Mover action: cache->user0 (cache:yes). Pool is above moving threshold percentage:   86% >= 65%.
Mar  5 12:28:12 Dammerung move: => Will smart move old files from cache to user0. Nothing will be moved from user0 to cache
Mar  5 12:28:12 Dammerung move: Adding Age
Mar  5 12:28:12 Dammerung move: Age (creation time) 15
Mar  5 12:28:12 Dammerung move: Filtering isos files... (can take a moment)
Mar  5 12:28:12 Dammerung move: Updated Filtered filelist: /tmp/ca.mover.tuning/Filtered_files_2025-03-05T122810.list for isos
Mar  5 12:28:12 Dammerung move: ----------------------------------------------------------- Processing [plex_lib] share ---------------------------------------------------------
Mar  5 12:28:12 Dammerung move: Primary storage: cache - size: 932GiB - used:  86 % (791GiB)
Mar  5 12:28:12 Dammerung move: Secondary storage: user0
Mar  5 12:28:12 Dammerung move: Share Information: Name: plex_lib - Path: /mnt/cache/plex_lib
Mar  5 12:28:12 Dammerung move: Moving threshold: 65% (606GiB) ; Freeing threshold: 25% (233GiB)
Mar  5 12:28:12 Dammerung move: Mover action: cache->user0 (cache:yes). Pool is above moving threshold percentage:   86% >= 65%.
Mar  5 12:28:12 Dammerung move: => Will smart move old files from cache to user0. Nothing will be moved from user0 to cache
Mar  5 12:28:12 Dammerung move: Adding Age
Mar  5 12:28:12 Dammerung move: Age (creation time) 15
Mar  5 12:28:12 Dammerung move: Filtering plex_lib files... (can take a moment)
Mar  5 12:28:12 Dammerung move: Updated Filtered filelist: /tmp/ca.mover.tuning/Filtered_files_2025-03-05T122810.list for plex_lib

 

I think the key is this: "Restore global settings" log entry.

 

I believe that the global settings are not being applied at the beginning and only get applied during the "restore global settings" step, which is why [plex_lib] is getting the correct setting in the second example.

Edited March 5, 20251 yr by ronia

9 hours ago, ronia said:

I think this data might be useful for the current issue

Thanks it is

10 hours ago, tehg said:

 

Is sometime plugin was working for cache prefer when low than freeing threshold it was moving data? 

Edited March 6, 20251 yr by Masterwishx

Thankyou for the hard work, I have been using this for a while. Just wondering if this would be easy enough to do.

Could you make an option to ignore hardlinks? Reason being is for seeding torrents. I would prefer those to stay on Pool until they are no longer seeding. This way I can keep only my 7 drive zfs pool spun up, and the array drives will only spin up if a file is actually being used. I'd like my pool drives to be powered down unless something is actually being read.

7 minutes ago, IllMethods said:

Could you make an option to ignore hardlinks?

I can check it, please open issue on github 

@alturismo

 

I think we need add separate thresholds and age? for cache prefer 

Not sure why in plugin we have :

 

elif [ "$POOLPCTUSED" -lt "$FREEINGPCTLIMIT" ]; then
                mvlogger "Mover action: $SECONDARYSTORAGENAME->$PRIMARYSTORAGENAME (cache:prefer). Pool is below priming threshold percentage: $POOLPCTUSED% < $FREEINGPCTLIMIT%."
                mvlogger "=> Will smart move newest files from $SECONDARYSTORAGENAME to $PRIMARYSTORAGENAME until threshold. Older files will be moved from $PRIMARYSTORAGENAME to $SECONDARYSTORAGENAME."
            

So I can add separate thresholds for cache prefer for not change code logic

Becouse not shure why move data when below freeing threshold for prefer. 

So users can set 95 to 0% and it will skip moving data like I made fix in last version... 

How exactly does "Synchronize Primary files to Secondary" work? I have it set, but the files don't seem to exist on both the primary and the secondary at the same time. Also if I use "Resynchronize all Primary files to Secondary" no files get synced at all. Am I doing something wrong or am I misunderstanding how the feature works?

2 hours ago, Meowcat285 said:

How exactly does "Synchronize Primary files to Secondary" work? I have it set, but the files don't seem to exist on both the primary and the secondary at the same time. Also if I use "Resynchronize all Primary files to Secondary" no files get synced at all. Am I doing something wrong or am I misunderstanding how the feature works?

Do you have set test mode to No? 

Since upgrading to the newest version of this plugin, with Masterwishx in the maintainer list, it does not appear to be working as I expect. 

 

When the cache is below the fill percent, I expect it to "prime" the cache.  When it is above the fill percent, I expect it to empty. Neither appears to be happening as I expect anymore. 

 

I have the threshholds set at 75%, and actual cache usage is at 82%, but it is not moving anything to array. 

 

Full mover log below, but what I consider to be the "important bits" is here.  I have no idea where the 0 and 99% are coming from. I do not have "per-share" settings set. 

 

Per the "auto age" instructions in the older version of the plugin, I have the share set to move cache<-array which is "backwards" but was apparently the way it is coded? 

 

Mar  7 13:33:22 Tower move: ------------------------------------------------------------- Processing [data] share -----------------------------------------------------------
Mar  7 13:33:22 Tower move: Primary storage: cache - size: 932GiB - used:  82 % (761GiB)
Mar  7 13:33:22 Tower move: Secondary storage: user0
Mar  7 13:33:22 Tower move: Share Information: Name: data - Path: /mnt/*/data
Mar  7 13:33:22 Tower move: Moving threshold: 99% (923GiB) ; Freeing threshold: 0% (0B)
Mar  7 13:33:22 Tower move: Mover action: user0->cache (cache:prefer). Pool is above freeing threshold percentage and below priming threshold percentage: 0% <  82% < 99%.
Mar  7 13:33:22 Tower move: => Skipping

 

Mar  7 13:33:17 Tower move: ***************************************************************** FILTERING FILES ***************************************************************
Mar  7 13:33:17 Tower move: ----------------------------------------------------------- Processing [appdata] share ----------------------------------------------------------
Mar  7 13:33:17 Tower move: Primary storage: cache - size: 932GiB - used:  82 % (761GiB)
Mar  7 13:33:17 Tower move: Secondary storage: none
Mar  7 13:33:17 Tower move: Share Information: Name: appdata - Path: /mnt/cache/appdata
Mar  7 13:33:17 Tower move: Mover action: no action, only cache used (cache:only).
Mar  7 13:33:17 Tower move: => Nothing will be moved. Share usage is taken into account in the calculation of the threshold for other shares.
Mar  7 13:33:17 Tower move: Calculating share usage... (can take a moment)
Mar  7 13:33:22 Tower move: cache/appdata used: 27GiB
Mar  7 13:33:22 Tower move: ------------------------------------------------------------- Processing [data] share -----------------------------------------------------------
Mar  7 13:33:22 Tower move: Primary storage: cache - size: 932GiB - used:  82 % (761GiB)
Mar  7 13:33:22 Tower move: Secondary storage: user0
Mar  7 13:33:22 Tower move: Share Information: Name: data - Path: /mnt/*/data
Mar  7 13:33:22 Tower move: Moving threshold: 99% (923GiB) ; Freeing threshold: 0% (0B)
Mar  7 13:33:22 Tower move: Mover action: user0->cache (cache:prefer). Pool is above freeing threshold percentage and below priming threshold percentage: 0% <  82% < 99%.
Mar  7 13:33:22 Tower move: => Skipping
Mar  7 13:33:22 Tower move: ----------------------------------------------------------- Processing [domains] share ----------------------------------------------------------
Mar  7 13:33:22 Tower move: Primary storage: cache - size: 932GiB - used:  82 % (761GiB)
Mar  7 13:33:22 Tower move: Secondary storage: none
Mar  7 13:33:22 Tower move: Share Information: Name: domains - Path: /mnt/cache/domains
Mar  7 13:33:22 Tower move: Mover action: no action, only cache used (cache:only).
Mar  7 13:33:22 Tower move: => Nothing will be moved. Share usage is taken into account in the calculation of the threshold for other shares.
Mar  7 13:33:22 Tower move: Calculating share usage... (can take a moment)
Mar  7 13:33:22 Tower move: cache/domains used: 0B
Mar  7 13:33:22 Tower move: ------------------------------------------------------------- Processing [isos] share -----------------------------------------------------------
Mar  7 13:33:22 Tower move: Primary storage: cache - size: 932GiB - used:  82 % (761GiB)
Mar  7 13:33:22 Tower move: Secondary storage: none
Mar  7 13:33:22 Tower move: Share Information: Name: isos - Path: /mnt/cache/isos
Mar  7 13:33:22 Tower move: Mover action: no action, only cache used (cache:only).
Mar  7 13:33:22 Tower move: => Nothing will be moved. Share usage is taken into account in the calculation of the threshold for other shares.
Mar  7 13:33:22 Tower move: Calculating share usage... (can take a moment)
Mar  7 13:33:22 Tower move: cache/isos used: 5.3GiB
Mar  7 13:33:22 Tower move: ------------------------------------------------------------- Processing [prv] share ------------------------------------------------------------
Mar  7 13:33:22 Tower move: Primary storage: cache - size: 932GiB - used:  82 % (761GiB)
Mar  7 13:33:22 Tower move: Secondary storage: user0
Mar  7 13:33:22 Tower move: Share Information: Name: prv - Path: /mnt/cache/prv
Mar  7 13:33:22 Tower move: Moving threshold: 99% (923GiB) ; Freeing threshold: 0% (0B)
Mar  7 13:33:22 Tower move: Mover action: cache->user0 (cache:yes). Pool is below moving threshold percentage:  82% < 99%.
Mar  7 13:33:22 Tower move: => Skipping
Mar  7 13:33:22 Tower move: ---------------------------------------------------------- Processing [shareddata] share --------------------------------------------------------
Mar  7 13:33:22 Tower move: Primary storage: cache - size: 932GiB - used:  82 % (761GiB)
Mar  7 13:33:22 Tower move: Secondary storage: user0
Mar  7 13:33:22 Tower move: /mnt/cache/shareddata does not exist. Is the share still used? Consider removing /boot/config/shares/shareddata.cfg if not.
Mar  7 13:33:22 Tower move: => Skipping
Mar  7 13:33:22 Tower move: ------------------------------------------------------------ Processing [system] share ----------------------------------------------------------
Mar  7 13:33:22 Tower move: Primary storage: cache - size: 932GiB - used:  82 % (761GiB)
Mar  7 13:33:22 Tower move: Secondary storage: none
Mar  7 13:33:22 Tower move: Share Information: Name: system - Path: /mnt/cache/system
Mar  7 13:33:22 Tower move: Mover action: no action, only cache used (cache:only).
Mar  7 13:33:22 Tower move: => Nothing will be moved. Share usage is taken into account in the calculation of the threshold for other shares.
Mar  7 13:33:22 Tower move: Calculating share usage... (can take a moment)
Mar  7 13:33:22 Tower move: cache/system used: 16GiB
Mar  7 13:33:22 Tower move: ************************************************************ ANALYSING MOVING ACTIONS ***********************************************************
Mar  7 13:33:22 Tower move: Deciding the action (move/sync/keep) for each file. There are 4 files, it can take a while...
Mar  7 13:33:22 Tower move: No new files will be moved/synced from primary to secondary
Mar  7 13:33:22 Tower move: No new files will be moved/synced from secondary to primary
Mar  7 13:33:22 Tower move: Cleaning lock and stop files
Mar  7 13:33:22 Tower move: ****************************************************************** WE ARE DONE ! ****************************************************************

 

34 minutes ago, Terebi said:

Full mover log below, but what I consider to be the "important bits" is here.  I have no idea where the 0 and 99% are coming from. I do not have "per-share" settings set. 

 

 

35 minutes ago, Terebi said:

Mar  7 13:33:22 Tower move: Mover action: user0->cache (cache:prefer). Pool is above freeing threshold percentage and below priming threshold percentage: 0% <  82% < 99%.

 

as your Share setting says "keep files on cache"

 

 

its the expected behaviour ...if it wasnt like this before, it was wrong before

thats also where the 99% hardcoded rule comes from (you can read the last posts about it), keep them on cache as hard as possible, thats what you want with this setting ...

 

this Share setting is the worst anyhow (personal opinion) specially in compagnion with this plugin.

 

so set to cache > array and then your tuner settings will be as expected

Just now, alturismo said:

 

 

as your Share setting says "keep files on cache"

 

 

its the expected behaviour ...if it wasnt like this before, it was wrong before

thats also where the 99% hardcoded rule comes from (you can read the last posts about it), keep them on cache as hard as possible, thats what you want with this setting ...

 

this Share setting is the worst anyhow (personal opinion) specially in compagnion with this plugin.

 

so set to cache > array and then your tuner settings will be as expected

 

This has always been "backwards" in my mind, but I swear there was a direct instruction earlier that this was the correct behavior to use the age-cache.   But I will try flipping it. 

48 minutes ago, alturismo said:

 

so set to cache > array and then your tuner settings will be as expected

It is actually broken when you have a share with array > cache - the mover is currently applying a 99% fill to all shares (despite setting a lower threshold in the config), regardless of whether it is cache > array or array > cache.  A global setting is applied to both (keep all on cache) and not moving older files to the cache > array set shares.  If you remove the array > cache (and set it to cache only) it works as expected.

 

(edit is to add a touch more context)

Edited March 7, 20251 yr by bbbilly05

This, but you can actually work around it by setting up another share (any share, it doesn't matter), to override the default settings.  This will force the mover to reapply the global settings for subsequent shares.  

 

For example, I used this on a share that I didn't really want anything moved off unless I needed emergency space:

 

11 hours ago, Terebi said:

When the cache is below the fill percent, I expect it to "prime" the cache.  When it is above the fill percent, I expect it to empty. Neither appears to be happening as I expect anymore. 

 

I have the threshholds set at 75%, and actual cache usage is at 82%, but it is not moving anything to array. 

 

Full mover log below, but what I consider to be the "important bits" is here.  I have no idea where the 0 and 99% are coming

This was temporary fix for cache prefer, working now on include sepate thresholds for cache prefer

9 hours ago, bbbilly05 said:

A global setting is applied to both (keep all on cache) and not moving older files to the cache > array set shares.  If you remove the array > cache (and set it to cache only) it works as expected.

Try to remove config file and set all again

11 hours ago, Terebi said:

Per the "auto age" instructions in the older version of the plugin, I have the share set to move cache<-array which is "backwards" but was apparently the way it is coded? 

It was really worked for you? I my testing for cache prefer it's moving to files to array and back to cache based on auto age, can't find on what really age it's based, so files going to cache and back to array every move when befor freeing threshold? 

 

Like @alturismo said it's not really how cache prefer should work. It need move all files to cache until full. 

So will try to add thresholds for cache prefer in this way

11 hours ago, Terebi said:

but I swear there was a direct instruction earlier that this was the correct behavior to use the age-cache

If you can find this instruction will be cool becose I'm trying to understand how the previous maintainer coded this to work.. 

2 hours ago, Masterwishx said:

If you can find this instruction will be cool becose I'm trying to understand how the previous maintainer coded this to work.. 

lets see ... as mentioned, its a "strange" setup in combo with this plugin anyway and always been "edge" handling with mover tuning

 

here sample from previous dev and when there where questions coming up

 

 

just as info note, its hard handling this "feature" side by side with mover tuning which actually "replaces" the feature more or less by keeping them long on cache (or forever).

 

the reason for cache prefer was usually, you run the mover once a day and may run into a filled up cache ... and in this case, cache prefer cache files may come back into cache (when they are not in use AND mover is running then AND there is free space).

 

why would this happen, as WITHOUT mover tuning you wouldnt run mover so often to free cache ...

now, WITH mover tuning, just put your "cache prefer" Shares to cache only, set the other Shares cache > array and let mover tuning run hourly, it will prevent starting mover and spinups until treehold is reached ... and when treehold is reached for Shares like Media, whatever, ... those Shares gets free and you never should run into issues with cache only Shares anyhow ... as the cache is freed up anyway now ...

 

i still cant imagine where the reason therefore should be (cache < array) IF you are using mover tuning ... and it will never satisfy all kinda situations with cache prefer (cache < array) Shares if you run this side by side, actually i cant imagine a scenario where this makes sense together ...

 

may i miss something

5 hours ago, alturismo said:

Shares if you run this side by side, actually i cant imagine a scenario where this makes sense together

Yep you are right, but seems people want use cache prefer.

So I'm trying to add thresholds for this when to move back to array like move when primary cache is after 95% freeing upto 90%.

 

But then it's same setting like cache yes thresholds but for cache prefer. 

 

I can make both fixed and then 

It's can be done in share override setting or I can make global setting also. Or to make fixed 95% when to move that can be overrides in share setting and global only freeing like 90%.

What do you think? 

 

5 hours ago, alturismo said:

here sample from previous dev and when there where questions coming up

Ohh seems it's find + sort and Inode. 

Thanks need to check not sure it's working right... 

i added thresholds for cache prefer it good and understood enough ? 

 

 

Edited March 8, 20251 yr by Masterwishx