Schwiing

Members
  • Posts

    52
  • Joined

  • Last visited

Posts posted by Schwiing

  1. I created a new ZFS pool with 4 disks (2 groups of 2 devices) - a 2 vdev mirror.  All went very well...added data and moved some stuff over from my XFS pools. I then put my docker containers on it and migrated the appdata over...all was working.

     

    I stopped the array to make another change..and it couldn't unmount my ZFS pool. I tried to do a lazy unmount, then I got:

    image.png.da9feb3f15594bb9dc39761cd0beef27.png

     

    (the pool name is thunder) over and over.

     

    Had to perform an unclean shutdown afterwards.

    Anything I did wrong?

  2. On 2/17/2023 at 8:00 PM, Reptar said:

    Chassis: RSV-L4500U

    Chassis Fans: 3x Noctua F12 PWM 54.97 CFM 120mm Fan

    Motherboard: MSI MEG X399 CREATION

    CPU: Threadripper 2990WX

    CPU Cooler: NH-U12S TR4-SP3 (Originally purchased NH-U14S TR4-SP3 -- Didnt fit)

    RAM: 8 x Corsair Vengeance RGB Pro 8 GB DDR4-3000 CL15 (had 4 sticks from previous build, reused and purchased additional)

    GPU: EVGA FTW GAMING ACX 3.0 GeForce GTX 1080 8 GB (Originally ASUS GTX1060 -- 1080 actually fits better!)

    PSU: Silverstone Strider 1500W 80+ Gold (Free from work many years ago)

    NIC:  Mellanox MCX311A

    HBA: LSI LSI00244 9201-16i (Upgraded to LSI 9300-16i -- Putting this in tomorrow!)

    NVMe Expansion: ASUS ‎HYPER M.2 X16 GEN 4 Card

    HDD Bay: 3 x Kingwin SSHD HD Enclosure Internal Five Hot Swap Bay (upgraded to SST-FS305-12G -- why upgrade? because SAS3 > SAS2)

    Rack: SYSRACKS 12U? I dont actually recall which one it is! If you do look at SYSRACK racks, I 100% recommend. It's worth the price for an enclosed rack. I recently purchased a home and decided to go open rack ( 27U -- also going in tomorrow!) 

    Current Array: 9 Drives, 1 Parity (90 TB Array) -- Still have 6 bays free. Eventually will upgrade parity to SAS drives and migrate the drives over to array.

    Cache Pools: 2 x 500GB SN570 (Docker/apps) , 2 x 2 x Sabrent Rocket Q 1TB (Download cache/VM)

     

    Overall, I would definitely like to go 3rd gen threadripper but the price was WAY too high at the time of purchase (still too high IMO)

    I will likely go with an Asrock Rack board once I do upgrade though!

     

     

    Primary Usecase: Nextcloud, Overseerr, Radar/Sonarr, Mastodon, Home Assistant -- Generally anything I want to use a computer for I will throw on BigChungus

     

    What really started me on this was the video on LTT's channel where they demo'd a machine learning application utilizing an ASUS coral AI accelerator. Eventually I will 100% purchase one of those and will feed my current UI cameras into some program that identifies people (this requires more PCI lanes/ports than my current setup offers though -- sounds like I need more upgrades!)

     

    EDIT: I forgot to mention, when I went from 32GB - 64GB RAM, I had to Purchase new 2 x 15MM ( 1 x NF-A12x15 and 1 x NF-A12x15 PWM chromax.black.swap -- why different ones? BECAUSE 2 OF THE NON-CHROMAX.BLACK ONES WOULDNT ARRIVE AT THE SAME TIME)

    noctua fans as the ones that came with the CPU cooler were too thick.. 

    image.png

    How was the fit with the SST-FS305-12G in the L4500U? Did you need to use the rails or did they fit well without them?

  3. The only issue I have is that I usually update all of my plugins before updating unRAID (based on advice from update assistant). In this case I'm hoping that by the time 6.12 stable comes out, there won't be an issue with leaving this plugin as-is until after the update

  4. Updated the plugin, ran the command but still no joy on the driver download.

    4 hours ago, danimal86 said:

    Just coming back to say that it seems to be fixed!

    Thanks for the ridiculously quick resolution to the problem!

     

    Any insight on what happened?

     

    Updated the plugin, ran the command and still failed to update the driver.

  5. 2 minutes ago, itimpi said:

    Nothing if that is the case - I thought you had it started earlier.

     

    Might want to check the times in the .cron file in the plugins folder are correct?  Also I am not sure if the switch to Summer time can affect such scheduling putting them an hour out?  Ad the moment 

     

    Looks correct to me:

     

    0 0 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
    0 7 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
    17 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

     

  6. Just now, itimpi said:

    Yes - but if you had already started the check before the fix for the syntax error was released then the plugin would have missed the fact it was a scheduled check.

     

    The check started on 4/1. The update was on 3-30. What am I missing?

  7. 1 hour ago, itimpi said:


    OK - sounds like the current issue is a side-effect of the fact the check started while there was a syntax error in the plugin and so there is probably not a new bug for me to fix.   If you see anything similar on a new check then please let me know.

     

     

    I'm confused. Wasn't the syntax error issue resolved with the 3-30 update? Or what syntax error are you referring to?

  8. 6 minutes ago, itimpi said:


    was this a new check or the original check still running?    The reason for asking is that if it was the original scheduled check then the plugin would not have caught the start due to the syntax error, and in such a case would assume that it must be a manual check as they do not have an event the plugin can catch so manual is then assumed by default.

     

    I wonder if it is worth me thinking about making a change to the logging so that there is a mode similar to the current ‘Testing’ mode where all log messages from the plugin are written to a log file in the plugins folder on the flash drive instead of or perhaps as well as the syslog.   This would give an easier way of seeing all plug-in messages for a complete run without filling up the syslog and would give a file it is easy for someone to send to me.  The original reason for using syslog was it often helps to see what the plugin was doing timewise relative to other things going on at the unRaid level.    Maybe use some radio buttons or check boxes opposite the logging option in Settings to allow the destination to be specified?  Logging to syslog does have the advantage of only going to RAM so avoiding unnecessary writes to the flash drive.   I’ll think about that as it should be easy to do and may well help with support.

     

     

    This was the original check that started at midnight on April 1st (Today). The pause time was scheduled for 0700 and when I checked at 0715, the check wasn't paused, then I started to troubleshoot.

  9. On the latest v3-30 plugin and this morning's parity check did not pause. Furthermore, if I try to set a different time for the pause while the parity check is running, 95% of the time the changes don't stick when hitting "apply". (i.e. changing the pause and resume times). I can toggle the scheduled check to yes or no, but the times usually don't change. I also tried reinstalling the plugin but the same behavior was exhibited. I'm on unraid 6.9.1.

    EDIT: Changing increment frequency to custom and changing the pause/resume times with crontab format work, but I can't enable sending notifications for pause or resume of increments. Strange.  I guess we'll see if it pauses at half past the hour, but it didnt at the top of the hour previously.


    EDIT 2: No joy. 30 7 * * * pause time had no affect and the parity check continues. Nothing in the log.

    EDIT 3: Changed the log level to testing (derp. Should have done that to begin with when I discovered it didn't work). Looks like the plugin thinks I kicked off a manual parity check, when it's actually a scheduled one:
     

    Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ----------- PAUSE begin ------
    
    Apr 1 07:37:01 ADRASTEA Parity Check Tuning: DEBUG: Pause request
    
    Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: /boot/config/forcesync marker file present
    
    Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: progress marker file present
    
    Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: manual marker file present
    
    Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: disks marker file present
    
    Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ... appears to be manual parity check
    
    Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ...configured action for MANUAL Correcting Parity Check: 0
    
    Apr 1 07:37:01 ADRASTEA Parity Check Tuning: TESTING: ----------- PAUSE end ------

     

    EDIT 4: Set "Use Increments for manual parity check" to "Yes" (for testing. Would prefer this to be off regularly) and it paused at the next scheduled time ( I set it to 40 7 * * * ). So, it pauses, but I guess it thought my scheduled check was manual somehow. That seems to be the conclusion of my report.

  10. 2 minutes ago, itimpi said:


    The basic plugin functionality to handle pause/resume of parity checks (and other array operations) and using increments works on all recent releases

     

    the features that require the 6.9.0 rc release are:

    • restarting parity checks from the point reached that were in progress when the system is shutdown or rebooted
    • the Partial parity checks used by the Parity Problems Assistant.

    These options are not available on the 6.8.3 release as they rely on some new low level functionality that is only present in the 6.9.0 rc releases.   If running on 6.8.3 the GUI will highlight what options cannot be used.   I had to decide between hiding such options in the GUI or leaving them visible (but disabled) with a message stating why they were disabled and went for leaving them visible.

     

    Many people now seem to think the current 6.9.0 rc2 stable to be used for their normal daily use. Hopefully 6.9.0 is not too far off leaving rc status and becoming the new stable release.  

    Cool, no worries, and thanks for the explanation.

     

    As long as it pauses and resumes properly for scheduled runs on stable, I'm happy :)

  11. 3 hours ago, itimpi said:

    Has anyone tried out the Parity Problems Assistant?

     

    At the moment I have set it up to not allow you to do anything if there is no parity disk present.   It occurred to me that in such a case I could allow a partial read-check rather than a parity-check.  Not sure if there are real-world scenarios where this might be useful?

    I'd be willing to try it if it were compatible with stable. Is there an incompatibility issue?

  12. 54 minutes ago, makkish said:

    Hello,

     

    I can confirm that my scheduled parity check did not pause either. I changed the settings and then back, the .cron look correct but it did not pause anyway.

     

    It did however pause correctly if I set "Use increments for Unscheduled Parity Check" to Yes.

    Yep, same here. That has been my temporary workaround for now, despite not wanting that behavior long-term.

  13. 2 minutes ago, itimpi said:


    this is much more likely to be a coding in the plugin where it is incorrectly saying it is aborted when it is not!

     

    it is only recently that the plug-in has even tried to generate a message at the end of the parity check.   The idea is that it will be more correct than the Jnraid generated one.    I am trying to stop both notifications coming out but if the plug-in one is misleading it may be better in the short term that they both come out.

     

    I would be interested in some feedback in what the parity history is saying for that particular check.   I think there is a good chance it will actually be correct.

    At least in my instance, the parity history looks like it finished the parity check, but also has an aborted message (when it paused). Strange. 



     

    sc.PNG

  14. 17 minutes ago, bidmead said:

    I'm puzzled by the notifications I found on my Dashboard this morning: a report that the parity check has concluded successfully, immediately followed by an error message from Parity Check Tuning that the parity check was aborted. (I am assuming that notifications are stacked newest uppermost.)

     

    My guess is that Parity Check Tuning is assuming that if it is set to run in increments of (say) three hours, any cessation of the parity check short of that time is "an abort". If this is right, unless the whole parity run mod 3 isn't exactly zero we're always going to see this "abort" notice.

     

    Can this be right? Please sanity check the conjecture from a relative newbie.

     

    -- 

    Chris

    Parity Check Aborted.png

     

    I got the same notification. Strange.

  15. I can only get my parity check to pause if i set "Use Increments for Unscheduled Parity Check:" to yes. Despite it being a scheduled event, I'm not sure why it won't pause unless setting this option to yes. I'm on Stable unraid with the latest plugin version.

  16. Right, which is very weird. Is there anywhere in my logs I can check if the memory is incompatible or anything else? I have 64GB of ram with no VMs and a handful of dockers that use ~11GB of RAM total. I can't figure out what the issue is.

  17. About once a week or so, my unraid server crashes and I'm not sure why. About 4 weeks ago, i swapped out my hardware from a dual xeon system to an EPYC 7302P with 64GB of DDR4-2400 ECC RAM. Everything seems to run fine until the server crashes in the middle of the night and I don't know why. I attached my diagnostics file. Any help running this down would be MUCH appreciated. Thanks.

    adrastea-diagnostics-20200623-0856.zip

  18. Thanks in advance for the help.

     

    Getting a lot of this in my syslog. Not sure what it means (seems related to my SAS controller but otherwise, no idea):

    May 26 05:05:13 ADRASTEA kernel: sd 3:0:4:0: Power-on or device reset occurred

    May 26 05:06:29 ADRASTEA kernel: mpt3sas_cm0: log_info(0x31110e03): originator(PL), code(0x11), sub_code(0x0e03)

     

    Anyone know what's going on?

     

    Diagnostics attached also.

    adrastea-diagnostics-20200526-0853.zip