[SOLVED] Question about how /etc/hdparm.conf is populated by OMV

    • OMV 5.x (beta)
    • Resolved

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • [SOLVED] Question about how /etc/hdparm.conf is populated by OMV

      If in OMV Storage | Disks I select all drives one by one and press the Edit button. Then I set Advanced Power Management, Automatic Acoustic Management, and Spindown Time all to Disabled and save the changes.

      When I look in /etc/hdparm.conf I see the following configuration for most of the disks:

      Source Code

      1. }
      2. /dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0FAHMNJ {
      3. write_cache = off

      However, for three of the disks (all are identical WD Red 3TB) I see this instead:


      Source Code

      1. /dev/disk/by-id/scsi-SATA_WDC_WD30EFRX-68_WD-WCC4N3YP9KRP {
      2. acoustic_management = 254
      3. apm = 1
      4. spindown_time = 120
      5. write_cache = on
      6. }
      7. }
      8. /dev/disk/by-id/scsi-SATA_WDC_WD30EFRX-68_WD-WMC4N0FAHMNJ {
      9. acoustic_management = 254
      10. apm = 1
      11. spindown_time = 120
      12. write_cache = on
      13. }
      14. /dev/disk/by-id/scsi-SATA_WDC_WD30EFRX-68_WD-WMC4N0F63YTM {
      15. acoustic_management = 254
      16. apm = 1
      17. spindown_time = 120
      18. write_cache = off
      Display All
      Note that two of the disks have write_cache set to on, and one is set to off.

      Is there something special about these disks that makes OMV override the settings I have made in the Storage | Disks panel? What makes OMV set different values for write_cache on otherwise identical disks?
      --
      Google is your friend and Bob's your uncle!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.
    • Can not confirm an abnormal behaviour here. OMV does nothing magic in the background. Double check your configuration.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • It's been triple checked.

      I even went so far as to delete the /etc/hdparm.conf file, make a small change to one drive in OMV Storage | Disks, save the changes, apply the configuration, and revert the changes. The /etc/hdparm.conf file is recreated and its contents are as above.
      --
      Google is your friend and Bob's your uncle!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.
    • Solved.

      Looking in config.xml <hdparm> section, the problematic disks were listed twice with differing UUIDs but the same serial numbers. I deleted the duplicate entries and /etc/hdparm is now normal.
      --
      Google is your friend and Bob's your uncle!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.