Question about SMART "Check Interval" Setting

  • I was trying to extend the SMART test interval from the default of 1800 (30 min) to something longer (like one day). I noticed the /etc/smartd.conf doesn't contain the information.


    Where is the updated time managed?


    Code
    # /etc/smartd.conf
    # Configuration file for smartd. Use "man smartd.conf" for more information.
    #
    # This configuration file is auto-generated.
    # WARNING: Do not edit this file, your changes will be lost.
    
    
    /dev/disk/by-id/ata-INTEL_SSDSC2BW120H6_CVTR5306006N120AGN -a -o on -S on -T permissive -W 0,0,0 -I 194 -I 231 -n standby,q -m x@gmail.com -M exec /usr/share/smartmontools/smartd-runner
    /dev/disk/by-id/ata-Samsung_SSD_850_EVO_500GB_S21HNXAG905578D -a -o on -S on -T permissive -W 0,0,0 -I 194 -I 231 -n standby,q -m x@gmail.com -M exec /usr/share/smartmontools/smartd-runner
    /dev/disk/by-id/ata-SAMSUNG_HM640JJ_S2AWJDNB303028 -a -o on -S on -T permissive -W 0,0,0 -I 194 -I 231 -n standby,q -m x@gmail.com -M exec /usr/share/smartmontools/smartd-runner
  • Sorry, I was vague in the question. I've entered the new time in the OMV GUI under SMART previously. I'm simply confirming that it gets set in the underlying files.


    I'm trying to debug a process that is spinning up my disk every 30 minutes and smartd looked like a good place to start looking as it has a 30 minute refresh period. I thought if I could confirm smartd is doing what it should, then I can rule it out and look elsewhere.


    I did run iotop and I collected some information about the process that is spinning the disk up:

    Code
    TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
     1444 be/3 root        0.00 K/s    3.84 K/s  0.00 % 99.99 % [jbd2/sdc1-8]


    Any idea what the jbd2/sdc1-8 command is and why it spins up the disk every 30 minutes?

  • It's the timing of it that is ultra-suspicious. Access is nearly 30 minutes on the dot.


    0 min: Disk spins up with jbd2/sdc1-8
    20 min: Disk Sleeps (20 minute timeout)
    30 min: Disk spins up with jbd2/sdc1-8
    Cycle Repeats.


    Why would the journal spin up the disk exactly every 30 minutes? Is it possible there is a process actually accessing the disk, but it doesn't show up in iotop, or would it show up there as well as the journal activity?

  • I'll try syslog tomorrow, that looks very promising for debugging what is causing it. In my mind I've narrowed it down to: Plex, SMART, or minidlna (in order of suspicion). I don't think I have anything else setup to access that shared folder/drive.

  • Looks like Plex (using syslog):

    Code
    [Mon Dec 28 04:00:05 2015] Plex Media Serv(3516): dirtied inode 19005726 (Plex Media Server.log) on sdc1
    [Mon Dec 28 04:00:05 2015] Plex Media Serv(3516): dirtied inode 19005726 (Plex Media Server.log) on sdc1
    [Mon Dec 28 04:00:05 2015] Plex Media Serv(3516): dirtied inode 19005726 (Plex Media Server.log) on sdc1
    [Mon Dec 28 04:00:11 2015] jbd2/sdc1-8(1453): WRITE block 45025024 on sdc1 (8 sectors)
    [Mon Dec 28 04:00:11 2015] jbd2/sdc1-8(1453): WRITE block 625215472 on sdc1 (8 sectors)
    [Mon Dec 28 04:00:11 2015] jbd2/sdc1-8(1453): WRITE block 625215480 on sdc1 (8 sectors)
    [Mon Dec 28 04:00:15 2015] jbd2/sdc1-8(1453): WRITE block 625215488 on sdc1 (8 sectors)
    [Mon Dec 28 04:00:20 2015] flush-8:32(12127): WRITE block 608174472 on sdc1 (8 sectors)


    Plex Sync is the exact culprit. Note the fact it updates the log every half hour.

  • The solution I'm leaning towards is using the same method the flashmemory plugin uses to cache the log directory:
    /media/e5f80c22-2bd8-427b-88f5-cad32e84e464/plexmediaserver/Library/Application Support/Plex Media Server/Logs


    This uses folder2ram and seems like a good solution. Any better suggestions?


    My preference is:
    1) folder2ram with the log directory.
    Pros/Cons: Least impact in needing to relocate plex and any issues with updates to plex. Least wear on SSD main drive.


    2) Relocate whole cache directory to the SSD.
    Pros/Cons: SSD doesn't need to spin up but will wear on the drive over time. Maybe issues when I upgrade Plex and cache isn't in standard location.

  • I've now solved the original problem of disk access, but on a side note, I did find that SMART isn't respecting the specified "Check interval" I've entered into the interface.


    I've entered: 86400


    It is checking about every 1 hour and 40 minutes:

    Code
    Dec 28 16:47:32 openmediavault smartd[2543]: Monitoring 3 ATA and 0 SCSI devices
    Dec 28 18:05:28 openmediavault smartd[2665]: Monitoring 3 ATA and 0 SCSI devices
    Dec 28 19:47:05 openmediavault smartd[2546]: Monitoring 3 ATA and 0 SCSI devices


    Not a big deal for me now that I've confirmed SMART isn't the culprit for disk spin-ups, but an interesting observation.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!