Jump to content

CS01-HS

Members
  • Posts

    479
  • Joined

  • Last visited

Posts posted by CS01-HS

  1. Any ideas even if they're guesses?

     

    I'm considering ordering a different m-pcie card to try and confirm the adapter's working but if I can probe either the controller or adapter in software that'd be better.

     

    Or if it's hopeless and I'm wasting my time that would also be good to know.

     

    Maybe I'll try running unraid from an M.2 sd card adaptor and surrendering all my USB ports to the VM.

  2. Split off from this thread.

    On 7/7/2020 at 12:24 PM, CS01-HS said:

    I have the Cyberpower 685AVRG and monitoring input voltage (grafana via NUT plugin) I've seen it dip as low as 110 without AVR kicking in, at least as far as I can tell. I have AVR set to high-sensitivity. Is that expected or maybe it's kicking in and I'm not detecting it?

     

    16 hours ago, Energen said:

    Were you able to set the values for AVR voltage?  I did some researching and playing around with the NUT plugin and the default value for input.transfer.low is 90w, which is the level I believe it needs to drop to in order for AVR to kick in.  That is quite the drop from standard USA electric power levels. 

     

    I haven't been able to figure out how to get that value to change.  I'm not sure which custom configuration file it should go in and the command line to change the value doesn't seem to do anything (upsrw -s input.transfer.low=100 -u admin -p adminpass ups) as far as updating any change to that level on the status page in unraid.

     

    NUT doesn't report an input.transfer.low for my CP685AVRG where AVR sensitivity's set with the unit's buttons.

     

    I know that to change the "low battery" setting required an additional flag (search here TUTORIAL: Networked NUT for Cyberpower UPS for "ignorelb")

  3. On 7/2/2020 at 1:20 PM, Energen said:

    Specifically, I'd get a UPS with AVR, automatic voltage regulation [...]  It keeps the voltage regulated at a nice steady 120v

    I have the Cyberpower 685AVRG and monitoring input volatage (grafana via NUT plugin) I've seen it dip as low as 110 without AVR kicking in, at least as far as I can tell. I have AVR set to high-sensitivity. Is that expected or maybe it's kicking in and I'm not detecting it?

     

    For the OP: I'm happy so far with this unit which is a lower-capacity version of some of the linked models. My only complaint is the hoops I had to jump through to get automatic restart working. APC works out of the box from what I've read.

  4. I saw sporadic CRC errors on my parity drive connected to the same ASM1062 (rev 2) controller, which forced multiple rebuilds.

     

    I'm pretty sure it wasn't a poorly-seated cable because I got the error again after swapping the drive to the other ASM1062 port. Right now I'm running parity off my HBA card to rule out a defective drive. Another possibility in my setup is defective cables (I used the same model cable for both ASM ports and only those ports.) I've changed out the cables for a known good model and if I don't see another CRC error in the next few weeks I'll swap parity back to the ASM and wait and see.

     

    I haven't ever had an error with the cache drives which are running off the integrated Intel controller.

    I really hope the problem isn't ASM/unRAID compatibility because correcting that will require a new MB.

  5. My motherboard is an Asrock J5005 .

    It has one PCIe slot where I have my HBA.

     

    I'm running the "macinabox" OS X VM and I'd like to pass my iPhone through to it to sync with iTunes.

    I tried passing it as a device but couldn't get it "seen" consistently or syncing at all.

     

    The recommended solution is to pass the whole controller but I can't do that because my board only has one (which hosts the unRAID boot USB, see 00.15.0)

    root@NAS:~# lspci
    00:00.0 Host bridge: Intel Corporation Gemini Lake Host Bridge (rev 03)
    00:00.1 Signal processing controller: Intel Corporation Celeron/Pentium Silver Processor Dynamic Platform and Thermal Framework Processor Participant (rev 03)
    00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 605 (rev 03)
    00:0e.0 Audio device: Intel Corporation Device 3198 (rev 03)
    00:0f.0 Communication controller: Intel Corporation Celeron/Pentium Silver Processor Trusted Execution Engine Interface (rev 03)
    00:12.0 SATA controller: Intel Corporation Device 31e3 (rev 03)
    00:13.0 PCI bridge: Intel Corporation Gemini Lake PCI Express Root Port (rev f3)
    00:13.1 PCI bridge: Intel Corporation Gemini Lake PCI Express Root Port (rev f3)
    00:13.2 PCI bridge: Intel Corporation Gemini Lake PCI Express Root Port (rev f3)
    00:13.3 PCI bridge: Intel Corporation Gemini Lake PCI Express Root Port (rev f3)
    00:15.0 USB controller: Intel Corporation Device 31a8 (rev 03)
    00:1f.0 ISA bridge: Intel Corporation Device 31e8 (rev 03)
    00:1f.1 SMBus: Intel Corporation Celeron/Pentium Silver Processor Gaussian Mixture Model (rev 03)
    01:00.0 RAID bus controller: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)
    03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
    04:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)

     

    So I tried to add another controller, thinking I could pass that.

    The only free slot on my board is an M.2 (Key E) slot.

     

    First I tried this M.2 NGFF Key A-E to Dual USB2.0 Extension Cable Card 

    320853082_ScreenShot2020-07-04at9_00_02AM.png.1c53dfa0ceaea2874d4b8689bf5fe25a.png

    which worked! but it's a hub not a controller so it didn't solve the problem.

     

    Next I searched for an M.2 USB controller but couldn't find any so I tried a workaround:

    an M.2 to mini PCIe adapter paired with a mini PCIe USB controller.

    M.2 (NGFF) Key A/E/A+E to Mini PCI-E Adapter 

    Mini PCI-E to USB3.0 Expansion Card

    2014165328_ScreenShot2020-07-04at9_07_47AM.png.b95e1f806c9c169101e6285cd8f808e0.png659824394_ScreenShot2020-07-04at9_09_28AM.png.821f9ff2940d245e25b30c48562fafc4.png

     

    I have this installed now but it's not recognized. The ports get power but the output of lscpi and lsusb (with a USB device attached) before and after installation are the same.

     

    Is there any diagnostic I can run to rule out a faulty card?

    Is there possibly another way to add a controller?

     

    Here's the output of lstopo (with --whole-io) in case it's useful, and thanks for any advice.

    topo_m2--whole-io.thumb.png.bb7f907b559f88ccd41e8c85795fc3ae.png

     

    EDIT [PARTIALLY SOLVED]:

    Just to follow up, I got it working with a different mini PCI card (linked below) although it's so slow it's almost unusable. Thankfully for my purposes (iphone pairing to enable wifi sync) that''s not a deal-breaker. I don't know whether the initial card was faulty or incompatible.

    Syba 19-Pin USB 3.0 Header Mini PCI-Express Card

    711suaAqwTL._AC_SL1308_.jpg.7f5b787888bcc898985ac7034348edfd.jpg

     

    lstopo before and after shows the card is recognized. Anyone know what those numbers connecting the PCI devices mean?

    lstopo_before_and_after.thumb.png.8ea409e5a11d1f9550deeea88f0cb202.png

  6. +1

     

    Adding "Automatic" as a cache option to populate it algorithmically based on access frequency and last-access-time would be great.

     

    It'd even make sense as the default because that matches new users' expectations.

     

    There should be a default threshold capacity (maybe configurable) or a "reserved" size because you don't want the cache drive 99% full.

    • Like 1
  7. Great plugin. I'm having one problem, maybe a misconfiguration on my part.

     

    I have two VMs I backup weekly:

    193846310_ScreenShot2020-06-08at6_15_43AM.png.2814616148d096676bc77bb8741712ed.png

     

    Both have the same problem: the primary vdisk from the last backup isn't deleted so there are always two, previous and current.

     

    Debian

    1162089101_ScreenShot2020-06-08at6_13_58AM.png.45c269337e6146607c09c4f6c7cbe29d.png

     

    MacOS

    1313608238_ScreenShot2020-06-08at6_14_55AM.png.82635b31f86be466e78c78cb4637360e.png

     

    I've tried changing number of days to 6 (thinking it might be a timing issue) but the plugin prevents it:

    2132126899_ScreenShot2020-06-08at6_15_56AM.png.5d9c05917204dea09719fa326209f935.png

     

    I've tried using number of backups instead of date but the plugin prevents that as well:

    1787418032_ScreenShot2020-06-08at6_16_12AM.png.380dd6348a4eea468171ca6eca572402.png

     

    Anyone know where I'm going wrong?

  8.  

    I should start with the disclaimer that I have no particular expertise with NUT so this guide is not definitive.

     

    I have a Cyberpower UPS (CP685AVR) powering a Raspberry Pi and my Unraid Server.

     

    Initially I installed apcupsd on the Pi, connected it to the UPS (via USB) and setup Unraid as slave. Install was fairly straightforward and worked well except for automatic restart after shutdown - when power's restored connected servers must be booted manually. (NOTE: If your CyberPower UPS is connected directly to your unRAID server, enabling Turn off UPS after shutdown in settings not only won't work but may cause the UPS to cut power without warning, forcing a parity check.)

     

    I settled on NUT running as master on the Pi (Debian-based) connected to the UPS via USB, with Unraid and all other clients as slaves.

     

    Overview

    We can trigger shutdown one of two ways - after a set amount of time on battery or at a set battery level.

     

    The timer method is more robust because if, after a power outage and shutdown, power's restored and the system boots but it's lost again, unraid may pick up the battery-level shutdown signal before the startup process completes which seems risky. And that may happen several times. 

     

    Instead we'll set NUT to shutdown clients after 20 minutes on battery (approximately 20% of my runtime capacity) so in theory it can handle a couple of these power's restored/power's lost cycles.

     

    Low battery will still trigger shutdown but the goal's to avoid a low battery condition.

     

    Let's get started:

     

    On Raspberry Pi

    sudo apt install nut

    # Verify UPS is visible with

    lsusb

    # Configure

    sudo emacs /etc/nut/ups.conf

    # My configuration block in ups.conf

    [cyberpower]
        driver = usbhid-ups
        port = auto
        desc = "UPS CP685AVR"
        offdelay = 20
        ondelay = 0
        ignorelb
        override.battery.charge.low = 20
        override.battery.charge.warning = 40
        pollinterval = 15

    A few notes about these settings:

    • offdelay says turn UPS off X seconds after master server shuts off, required for automatic restart
    • ondelay should be 30 (10s greater than off delay) but a cyberpower bug requires 0 to avoid unexpected power cuts (similar to apcupsd behavior)
    • a shorter pollinterval is required to prevent the Pi (and maybe other debian systems) from losing contact
    • ignorelb allows custom overrides for battery.charge

     

    # Start

    upsdrvctl start

    # Configure nut upsd

    sudo emacs /etc/nut/upsd.conf

    # Add network request listener replacing <Pi IP> with your Pi's IP address

    LISTEN <Pi IP> 3493

    # User setup

    sudo emacs /etc/nut/upsd.users

    # Add users for admin, monitoring, local and remote users replacing pwd with your preferred password

    [admin]
            password = pwd
            actions = SET
            instcmds = ALL
    [local]
            password  = pwd
            upsmon master
    [remote]
            password  = pwd
            upsmon slave
    [monuser]               
            password  = pwd
            upsmon slave

    # Configure monitoring

    sudo emacs /etc/nut/upsmon.conf

    # Change the following values:

     

    # Increase slave shutdown wait period to 10 minutes (worst case)

    HOSTSYNC 600

    # Works with pollinterval setting to prevent USB disconnection

    DEADTIME 25

    # Alerting twice/day about a battery change is excessive, make it once

    RBWARNTIME 86400

    # To be safe give clients an additional 90 seconds to fully shutdown                                                                                                             

    FINALDELAY 90

    # Add monitor replacing pwd with the password you specified for [local] above

    MONITOR cyberpower@localhost 1 local pwd master

    # Timed shutdown - see upssched.conf for details                                                                                                                                    

    NOTIFYCMD /sbin/upssched
    NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
    NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
    NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC

     

    # Set the schedules in upssched.conf:

    sudo emacs /etc/nut/upssched.conf

    # Verify it has the line

    CMDSCRIPT /bin/upssched-cmd

    # Add:

    # Command pipe and lock-file
    PIPEFN /var/run/nut/upssched.pipe
    LOCKFN /var/run/nut/upssched.lock
    
    # Send alerts immediately on change in line power
    AT ONBATT * EXECUTE onbatt
    AT ONLINE * EXECUTE onpower
    
    # (Optional) Silence the beeper after 2 minutes
    AT ONBATT * START-TIMER mute_beeper 120
    AT ONLINE * CANCEL-TIMER mute_beeper
    
    # Shutdown after 20 minutes on battery (20 * 60 = 1200)
    AT ONBATT * START-TIMER onbatt_shutdown 1200
    
    # Cancel timer if power's restored
    AT ONLINE * CANCEL-TIMER onbatt_shutdown
    
    # Battery replacement indicated by cron'd quick test
    AT REPLBATT * EXECUTE replace_batt

     

    # Customize the executable called by upssched

    sudo emacs /bin/upssched-cmd

    # ...by replacing existing code with the following (substituting the password you set for admin earlier for <pwd>)

    # START: User-specific settings                            
    #
    UPS_USERNAME="admin"
    UPS_PASSWORD="<pwd>"
    UPS_LINK="cyberpower@localhost"
    # END  
    
    case $1 in
        onbatt)
            # make sure beeper is enabled
            upscmd -u ${UPS_USERNAME} -p ${UPS_PASSWORD} ${UPS_LINK} beeper.enable
            # alert
            message="Power outage, on battery"
            logger -t upssched-cmd "$message"
            ;;
        onpower)
            message="Power restored"
            logger -t upssched-cmd "$message"
            ;;
        mute_beeper)
             message="(2) minute limit exceeded, muting beeper"
             upscmd -u ${UPS_USERNAME} -p ${UPS_PASSWORD} ${UPS_LINK} beeper.mute
             ;;
        onbatt_shutdown)
            message="Triggering shutdown after (20) minutes on battery"
            logger -t upssched-cmd "$message"
            /sbin/upsmon -c fsd
            ;;
        replace_batt)
            message="Quick self-test indicates battery requires replacement"
            logger -t upssched-cmd "$message"
            ;;
        *)
            logger -t upssched-cmd "Unrecognized command: $1"
            ;;
    esac

    # Verify it's executable by all:

    ls -l /bin/upssched-cmd

     

    # Schedule the (weekly) quick test mentioned earlier

    sudo crontab -e

    # Add

    # Weekly UPS self-test
    0  2  *   *   MON       /bin/upscmd -u admin -p <password from upsd.users>  cyberpower@localhost test.battery.start.quick

     

    # Configure nut as netserver

    sudo emacs /etc/nut/nut.conf

    # Change MODE

    MODE=netserver

     

    Now reboot the Pi to verify the NUT services launch on startup

     

    # Confirm services are running

    sudo service nut-server status
    sudo service nut-client status

    # Confirm communication with UPS - this should return a bunch of info

    upsc cyberpower

     

    On Unraid

     

    # Install NUT from CA

     

    # Configure as follows using the Pi IP, monuser password and remote password specified earlier

    # NOTE: Whether in the case of a timed shutdown or an emergency low battery shutdown

    #            we're relying on the Pi (NUT server) to send the signal. Ideally the shutdown triggers here 

     #           won't be used.

    1208822292_ScreenShot2021-01-23at5_33_32AM.thumb.png.3bb0b7cbf27e6b7b8330e729573cfe3a.png

     

    Miscellaneous 

     

    # Test shutdown.

    # NOTE: This will shutdown your system so it's safest if you stop the array first. 

    #           But stopping is most of the required shutdown time, so after you confirm

    #           this works you might want to test again without stopping the array.

    sudo upsmon -c fsd


    EDIT: 4/2024 - Customization of the nut plugin (below) isn't compatible with the latest version, and unnecessary now that these additional power states are incorporated.

    Spoiler

    Optional

     

    # Cyberpower uses status codes not recognized by the NUT plugin which as far as I can tell only affect display but I want my dashboard to be pretty so let's customize the display script (NOTE: this will get overwritten, and possibly cause conflicts, on plugin update)

    mkdir /boot/extras/nut
    cp /usr/local/emhttp/plugins/nut/include/nut_status.php /boot/extras/nut/nut_status.php
    vi /boot/extras/nut/nut_status.php

    # Replace the state array with the following

    $state = [
      'OL'             => 'Online',
      'OL CHRG'        => '<span class="orange-text">Online: charging</span>',
      'OL CHRG LB'     => '<span class="orange-text">Online: charging</span>',
      'OL DISCHRG'     => '<span class="orange-text">Online: discharging</span>',
      'OL DISCHRG LB'  => '<span class="orange-text">Online: discharging</span>',
      'OL BOOST'       => '<span class="red-text">Online: low voltage</span>',
      'OB DISCHRG'     => 'Offline: On battery',
      'OB LB'          => 'Offline: Low battery'
    ];

     

    # If you prefer the look of the built-in UPS dashboard, the next two sections (presented in diff form) mimic it

    # diff /usr/local/emhttp/plugins/nut/include/nut_status.php.orig /usr/local/emhttp/plugins/nut/include/nut_status.php
    44,45c48,49
    <       $runtime   = gmdate("H:i:s", $val);
    <       $status[2] = strtok($val/60,' ')<=5 && !in_array('ups.status: OL', $rows) ? "<td $red>$runtime</td>" : "<td $green>$runtime</td>";
    ---
    >       $runtime   = strtok($val/60,' ');
    >       $status[2] = strtok($val/60,' ')<=5 && !in_array('ups.status: OL', $rows) ? "<td $red>".intval($runtime)."m</td>" : "<td $green>".intval($runtime)."m</td>";
    49a54,56
    >     case 'input.voltage':
    >       $voltage   = intval(strtok($val,' '));
    >       break;
    64c71
    <   $status[3] = $power==0 ? "<td $red>${power}w</td>" : "<td $green>${power}w</td>";
    ---
    >   $status[3] = $voltage<114 ? "<td $orange>${voltage}V</td>" : "<td $green>${voltage}V</td>";
    # diff /usr/local/emhttp/plugins/nut/nutFooter.page.orig /usr/local/emhttp/plugins/nut/nutFooter.page
    151a152
    > <span class='ups'>Input voltage:</span><span class='nut_nompower'></span><br>
    154d154
    < <span class='ups'>Nominal power:</span><span class='nut_nompower'></span><br>

     

    # Set your go file to overwrite the default files with the customized version on boot

    vi /boot/config/go

    # Add to the end:

    # Customize nut (UPS) display
    cp /usr/local/emhttp/plugins/nut/include/nut_status.php /usr/local/emhttp/plugins/nut/include/nut_status.php.orig
    cp /boot/extras/nut/nut_status.php /usr/local/emhttp/plugins/nut/include/nut_status.php
    # display voltage instead of max power
    cp /usr/local/emhttp/plugins/nut/nutFooter.page /usr/local/emhttp/plugins/nut/nutFooter.page.orig
    cp /boot/extras/nut/nutFooter.page /usr/local/emhttp/plugins/nut/nutFooter.page

     

     

     

     

    All done. Automatic shutdown of the servers and UPS work and (assuming proper BIOS settings) they'll all restart when power's restored.

     

    Edit 7/6/2020: Increase offdelay to account for slow unraid shutdown 

    Edit 1/23/2020: Misc reliability tweaks, shift from battery level-based shutdown to timer-based shutdown

    Edit 4/20/2024: Hide nut plugin customization which is incompatible with later versions.

  9. I have a USB HDD in unassigned devices which I use for backups. The drive won't spin down for whatever reason, mounted or not.

     

    My solution was a modified version of this script that I have User Scripts run every hour.

    It takes a list of drives, checks for activity and spins them down if they're inactive and spun up.

     

    I thought I'd share it.

     

    NOTE: The green "led" in Unassigned Devices stays green even when the drive's spun down, I don't know how or if it detects power status.

    #!/bin/bash
    # This script looks for recent disk access, and if nothing has changed, puts /dev/disk/by-id/${drive} into spindown mode.
    #
    # Set your drive identifiers (listed in /dev/disk/by-id/) ignoring characters after the last "-"
    # e.g. listing: usb-WD_My_Passport_25E2_75831314363630505A37-0:0
    #   becomes: usb-WD_My_Passport_25E2_75831314363630505A37
    drives=(
      "<DRIVE_IDENTIFIER_1>"
      "<DRIVE_IDENTIFIER_2>"
    )
    
    # spindown delay in minutes
    SPINDOWN_DELAY=30
    
    # Uncomment to enable debug mode
    #DEBUG=true
    
    # Set the directory where the status files will be stored,
    # /tmp/ is a fine default
    STATUS_DIR="/tmp"
    
    current=`date`
    
    # create status_dir if it doesn't exist
    mkdir -p ${STATUS_DIR}
    
    do_device() {
        local device_id=$1
        device=`ls -l /dev/disk/by-id/ | grep ${device_id} | head -1 | tail -c4`
        filename="${STATUS_DIR}/diskaccess-${device_id}.status"
    
        is_awake=`smartctl --nocheck standby -i /dev/${device} | grep 'Power mode is' | egrep -c 'ACTIVE|IDLE'`
        if [ "${is_awake}" == "1" ]; then
            if [ "$DEBUG" = true ]; then
                echo "${device} is awake"
            fi
    
            stat_new=$(grep "${device}1 " /proc/diskstats | tr -dc "[:digit:]")
    
            if [ ! -f "${filename}" ]; then
                echo ${current} "- ${filename} file does not exist; creating it now."
                echo ${stat_new} > ${filename}
            else
                stat_old=`cat ${filename} | tr -dc "[:digit:]"`
    
                # calculate minutes since last update to see if we should sleep
                current_time=$(date +%s)
                last_mod=$(stat ${filename} -c %Y)
                seconds_ago=$(expr $current_time - $last_mod)
                minutes_ago=$(expr $seconds_ago / 60)
    
                if [ "$DEBUG" = true ]; then
                    echo "${device} old stat: ${stat_old}"
                    echo "${device} new stat: ${stat_new}"
                    echo "${device} new stat modified ${minutes_ago} minutes ago"
                fi
    
                if [ "${stat_old}" == "${stat_new}" ]; then
                    if [ $minutes_ago -ge $SPINDOWN_DELAY ]; then
                        echo ${current} "- Drive /dev/${device} is awake and hasn't been used in ${minutes_ago} minutes; spinning down"
                        hdparm -y /dev/${device} > /dev/null 2>&1
                    else
                        echo ${current} "- Drive /dev/${device} was last used ${minutes_ago} minutes ago, less than spindown setting ($SPINDOWN_DELAY)"
                    fi
                else
                    echo ${current} "- Drive /dev/${device} has been used..."
                    echo ${stat_new} > ${filename}
                fi
            fi
        else
            if [ "$DEBUG" = true ]; then
                echo "${device} is asleep"
            fi
        fi
    }
    
    for device_id in ${drives[*]}
    do
        do_device ${device_id}
    done

     

     

    • Like 1
  10. With the official EmbySever container, follow the instructions here, substituting Emby where appropriate:

     

    Then go to Main -> Flash -> Syslinux Configuration -> Unraid OS

    and change the line:

    append initrd=/bzroot

    to

    append initrd=/bzroot intel_iommu=igfx_off

    Hit "Apply" and reboot.

     

    At this point hardware encoding should be working but the video output will be garbled. Follow instructions here to resolve that:

     

    • Thanks 1
  11. 12 hours ago, xxnumbxx said:

    Anyone successful in passing through a iPhone to this VM? I can pass-through USB sticks just fine but no luck with a iPhone. I saw a couple of others have the same issue.

    I'm in the same boat. External disks work consistently, iPhone not at all.

     

    Unfortunately my board has a single integrated USB controller and no free PCIe slot so the "pass a controller" solution doesn't work. I tried VirtualHere (USB over ethernet) but apparently iPhone sync with a Mac host requires a Mac client. That didn't work in my case but may work for others.

  12. Same. Tell me if this makes sense:

     

    In "target mode" there are two basic conditions to handle:

    (1) a large cache write

    (2) many small or medium cache writes

     

    Case (1) has the potential to fill the drive if a high target (say 75%) is specified, so mover must run frequently enough to detect it and free cache space.

     

    With frequent mover runs, assuming the age logic is granular (find sorted by age and iterate the files summing size), case (2) will cause very frequent array writes as a handful of files are moved on each run to maintain the target %. Better then to move the old files off in larger chunks, time rounded to the day (e.g. first all files older than 30 days from current date at 12am, then all older than 29, etc.)

     

    That was all preface (sorry!) to answer your question:

     

    I think it's almost entirely a UI decision. You could handle a target % and complex rules in code by calling your current rules logic in a loop from e.g. i=30 down, find older than i days until target free space is reached. And if it fails to free enough space that's on the user.

     

    Your "Or..." which is my preference (your range is good), would be similar but skip over the complex rules logic avoiding failures due to user error.

     

    Both proposals are a little hack-y (maybe you have a better idea) but I think until smart caching's built in every solution will be somewhat hack-y. 


    I really appreciate this exchange but please don't let me derail what's obviously a popular plugin to handle my (potentially minority) use case.

  13. I'm all caught up on the thread. Just thinking out loud but maybe an easier method that gets most of the benefits is to use last-modified (as you do in the age setting) and when a user-specified target cache % is exceeded iterated find commands (which should be cheap on an SSD) slice off the oldest files until the target % is restored.

  14. 14 minutes ago, hugenbdd said:

    Shares are mounted with atime excluded...

    Well that makes things tougher! I wonder if SMB/AFP requests could be intercepted and stored with a timestamp. Thanks for the direction, I'll read up.

  15. 1 hour ago, hugenbdd said:

    Bug fix release just now. (5/11/2020)

     

    Added ability for spaces in share names (quotes around share path) and fixed spelling mistake.

     

    Glad I could contribute a little and thanks for a great plugin.

     

    All was well with my cache until I added time machine - now my once-sleepy parity disk (and every other disk thanks to turbo write) never rest. Mover Tuner has helped greatly but I'm thinking for my purposes (media and Time Machine) a cache that stays relatively full and evicts based on last access date would be ideal. I'll research to see if that's even possible and how difficult it would be and maybe write something.

  16. I think there's a bug where the script doesn't quote share directories so e.g. a share with the name "Time Machine" will cause this error:

    May 11 05:42:07 NAS root: find: '/mnt/cache/Time': No such file or directory
    May 11 05:42:07 NAS root: find: 'Machine/': No such file or directory

    which I hadn't seen previously (though it's possible I missed it.)

     

    It's probably not best practice to include spaces in share names and I've solved it by renaming but thought I'd mention it.

     

    Great plugin by the way, thanks.

×
×
  • Create New...