Jump to content

limetech

Administrators
  • Posts

    10,192
  • Joined

  • Last visited

  • Days Won

    196

Report Comments posted by limetech

  1. 21 minutes ago, nexusmaniac said:

    Seems I'm seeing a lack of spindowns too on RC1 🥴

     

    I've attached a diagnostic with all devices spun up ... then after I've manually spun the array down and all the devices have spun back up again 'on their own' (possibly due to SMART).raptor-diagnostics-20201211-1819.zipraptor-diagnostics-20201211-1814.zip

    Messages like this:

    Dec 11 08:51:04 Raptor emhttpd: read SMART /dev/sdj

    mean that we have detected I/O on a device that has been previously spun-down.  We issue a 'smartctl -A' command to the device (which is now spun-up) to read its temperature.  Probably this would be better wording:

     

    "I/O detected on device /dev/sdj, reading SMART"

     

    Probably a plugin is responsible for this.

  2. 35 minutes ago, SimonF said:

    Beginning of startup missing from syslog.

     

    First entry after reboot.

     

    Dec 10 18:05:53 Tower root: This plugin requires Dynamix webGui to operate

    In webGUI Tools/Syslog right?  That window displays only the last 1000 lines.  This releases includes a little more debug info I'm outputting the log and it's probably sending it over the limit.  The file itself /var/log/syslog is intact.  We'll see about adding pagination.  Thanks for the report.

  3. 15 minutes ago, DarkMan83 said:

    With my controller i can use "cciss" or "sat" ( where smartctl suggests "cciss" as you can see in the screen)...regardless which one i choose no temps in main. Smart data is working for me we with either of them.

     

    In another topic i can't remember it was already confirmed, that selecting a specific controller type (regardless which one) is ignored for the command that reads the temps, seems that the controller type value isn't properly used to build the command with the needed params...

    Ok, thank you.

  4. 1 hour ago, Gnomuz said:

    they are rarely open in front of you, especially in the case of an unexpected crash in the middle of the night or during the weekend

    Debugging relies very greatly on being able to repeat the problem.  If someone experiences a crash and they just say, "hey it crashed", well nothing much to do about that.  But if they create the same conditions that led to the crash before and, anticipating a crash might soon happen, have a terminal window open, then that might be able to capture enough output to be useful.  That was my point.

  5. 48 minutes ago, Gnomuz said:

    Let's say that on July 19th 2020 (date of the OP), it may have been considered as "Minor", but on November 23rd 2020, more than 4 months later, without any reaction or acknowledgement in the meantime, I'm sure you understand the "Urgent" tag was a kind of desperate "message in a bottle" ...

    Moreover, as @Dataonestated above, and I completely agree with him, I hardly would qualify as "Minor" a bug which prevents from preserving syslogs in case of a crash, and thus prevents any serious diagnostic on the root cause, especially on beta versions we are happy to test and debug with you.

    Anyway, glad to see it has been taken into account and we'll be able to retest in the next beta release !

    There are other ways of capturing logs:

    • direct to a syslog server on another machine
    • have the webgui Log window open
    • have a terminal window open running 'tail -f /var/log/syslog'

     

    I get some people think this what they consider "urgent" but sorry I have to be somewhat strict or else ever single bug report will be marked urgent (because it's always "urgent" to the reporter).

  6. 15 minutes ago, Tomr said:

    They don't state that the files will be orphaned if the setting are changed,

    They are not orphaned in the sense they become invisible.  No matter what settings of Use cache, all files across all disks/pools will be shown for a share.

     

    15 minutes ago, Tomr said:

    whole things with hardlinks

    All that means is: if you have a hard link to a file, when that file gets moved, the hardlink also gets moved in the sense that it gets created in the destination.  So if you have:

     

    /mnt/user/myshare/file

    /mnt/user/myshare/hardlink-to-file

     

    and file and hardlink-to-file is on say, 'cache', then when file is moved to array, whatever disk it ends up on we also create on that disk hardlink-to-file.

  7. You are describing correct behavior as it was designed.  If you want to change a share from cache 'yes' to cache 'no' and have files moved off cache pool, you should first invoke mover (Move Now button) to move all those files and then change Use cache config from 'yes' to 'no' so that future new files are written only to array.

     

    Having said that, I can see how this can be unexpected behavior depending on how you interpret the config settings.  Current use of the 'mover' is pretty simple, but the functionality exists to add quite a bit more sophistication.  This is a "future feature" item 8)

×
×
  • Create New...