Hallo zusammen!

Ich habe mir als Backup-Speicher für meinen Heimserver eine Seagate Exodus 18TB NAS HDD angeschafft.
Das Problem, dem ich jetzt aber begegne: Die HDD geht nicht in den Idle.

Mittels hdparm kann ich einen Idle Timer von fünf Sekunden festlegen, doch die HDD geht trotzdem - selbst nach Minuten - nicht in Idle-Modus.

sudo hdparm -S 1 /dev/sda      

/dev/sda:
 setting standby to 1 (5 seconds)

Mit iostat erhalte ich folgende Daten:

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
sda               0.08         1.24         0.00         0.00       1953          0          0

Höre ich genau hin, bzw. fühle an der HDD, so kann ich ein minimales Ticken feststellen. Zwar kein "richtiges" Kratzen aber dennoch genug, damit man sie nicht in Idle versetzen kann.
Das habe ich unter zwei Rechnern probiert (einmal Arch, einmal Debian-basis) und tritt sogar ungemounted, mit ext4 (was soweit ich weiß kaum fragmentieren dürfte) sowie ohne Dateisystem auf (direkt nach fdisk GPT-Partitionierung)

Output von sudo hdparm -I /dev/sda ist:

/dev/sda:

ATA device, with non-removable media
        Model Number:       ST18000NM000J-2TV103                    
        Serial Number:      Z******G
        Firmware Revision:  SN01    
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Used: unknown (minor revision code 0xffff) 
        Supported: 11 10 9 8 7 6 5 
        Likely used: 11
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors: 35156656128
        Logical  Sector size:                   512 bytes [ Supported: 512 4096 ]
        Physical Sector size:                  4096 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:    17166336 MBytes
        device size with M = 1000*1000:    18000207 MBytes (18000 GB)
        cache/buffer size  = unknown
        Form Factor: 3.5 inch
        Nominal Media Rotation Rate: 7200
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Recommended acoustic management value: 254, current value: 0
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4 
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    DOWNLOAD_MICROCODE
                Power-Up In Standby feature set
           *    SET_FEATURES required to spinup after power up
                SET_MAX security extension
           *    48-bit Address feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    Media Card Pass-Through
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
           *    IDLE_IMMEDIATE with UNLOAD
                Write-Read-Verify feature set
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    unknown 119[6]
           *    unknown 119[7]
                unknown 119[8]
                unknown 119[9]
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Gen3 signaling speed (6.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Phy event counters
           *    Idle-Unload when NCQ is active
           *    READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
           *    DMA Setup Auto-Activate optimization
                Device-initiated interface power management
           *    Software settings preservation
                unknown 78[7]
           *    SMART Command Transport (SCT) feature set
           *    SCT Write Same (AC2)
           *    SCT Error Recovery Control (AC3)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
                unknown 206[7]
                unknown 206[12] (vendor specific)
                unknown 206[13] (vendor specific)
                unknown 206[14] (vendor specific)
           *    SANITIZE_ANTIFREEZE_LOCK_EXT command
           *    SANITIZE feature set
           *    OVERWRITE_EXT command
           *    All write cache is non-volatile
           *    Extended number of user addressable sectors 
Security: 
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        1554min for SECURITY ERASE UNIT. 1554min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 500******b13fd59
        NAA             : 5
        IEEE OUI        : 0****0
        Unique ID       : 0******59
Checksum: correct

Mit meiner Seagate Barracuda 6TB HDD tritt dies nicht auf (ich kann sie problemlos über hdparm schlummern lassen) und auch sonst habe ich dieses Verhalten bisher nicht erlebt.

Meine Vermutung war, dass es evtl. damit zusammenhängt, dass es sich um eine NAS HDD handelt.
Meine Recherche hat jedoch ergeben, dass es dort allerhöchstens eine konstante Rotation der Schreibnadel gibt, dieser minimal Lesezugriff bzw. das daraus resultierende leichte Kratzen kann ich mir damit nicht ableiten.

Hat jemand Vorschläge womit das zusammenhängen kann oder Ideen was man noch messen könnte?
LG

  • Dirk und chepaz haben auf diesen Beitrag geantwortet.

    Blowback tritt sogar ungemounted, mit ext4 (was soweit ich weiß kaum fragmentieren dürfte) sowie ohne Dateisystem auf

    Da sollte die Fehlerquelle wohl eher im Controller des NAS gesucht werden, als bei Arch, oder? Hat das NAS eine Weboberfläche, über die man das eventuell konfigurieren könnte? Vielleicht ist die Festplatte einfach nicht „kompatibel genug“ …

    Ist tatsächlich kein fertiges NAS (wie Synology oder QNAP). Es handelt sich um einen gewöhnlichen x86 Computer mit Debian als Server OS.
    Um auszuschließen, dass es irgendwie an dem Rechner oder Debian liegt, habe ich es auch unter meinem Arch-Desktop probiert: gleiches Ergebniss.

    Wende mich daher ans Hardware-Forum von Arch. Vielleicht hat hier ja jemand mehr Erfahrung auf diesem Gebiet und hat eine Idee womit das zu tun haben könnte.

    Edit: Alle drei Tage sollen nämlich automatisiert Backups auf diese HDD erstellt werden.
    Weil der Server im Wohnbereich steht (Desktop-Gehäuse ...), soll die HDD die restliche Zeit so leise wie möglich und daher im Idle sein.

    Blowback Recommended acoustic management value: 254, current value: 0

    Probier mal den Wert hier umzusetzen, ich meine mich zu erinnern das Acusticmanagement früher(tm) da manchmal aus sein musste (oder >128 oder sowas) bei manchen Platten.

    Guter Einfall @chepaz!
    Tatsächlich kommt das dem Problem näher:

    sudo hdparm -M /dev/sda  
    
    /dev/sda:
     acoustic      = not supported

    AAM scheint also nicht unterstüzt zu sein.
    Abgesehen davon, dass ich es schade finde, dass man das in den Produktdaten nirgends findet, bin ich mir jedoch nicht ganz sicher ob das auch die Ursache für das non-idling Problem ist.
    Was meint ihr?

    • chepaz hat auf diesen Beitrag geantwortet.

      Schau dir auch mal diese Wiki-Seite an:
      https://wiki.archlinux.org/title/Hdparm#Power_management_configuration

      Ich hab grad mal bei meiner getestet, das funktioniert.
      Ausgehend vom Wiki wäre interessant die Ausgaben von (gehe von /dev/sda aus):

      hdparm -B /dev/sda
      hdparm -M /dev/sda (bei mir kommt: acoustic not supported)
      
      (interessant finde ich den Hinweis auf Abfrage des Status über smartctl, evtl. ist deine HD ja im Standby-Modus(also Motor aus):
      smartctl -i -n standby /dev/sda

      N.B.: smartctl ist im Paket smartmontools
      //Edit: An irgendwelchen "Diskmanagern" etc. von irgendwelchen Desktop-Managern bzw. überhaupt an externen Vorgängen - die die Platte ggf. wieder aufwecken - kann es nicht liegen?

      //Edit 2: Obige Abfrage des Status (smartctl weckt die Platte im Gegensatz zu hdparm ja nicht auf) kann auch komfortabel mittels watch in Intervallen abgefragt werden:
      watch -n 2 smartctl -i -n standby /dev/sda
      Führt smartctl alle 2 Sekunden aus. (Ich liebe watch <g>)

      //Edit3: Der Power-Mode ist ja entweder active/idle oder (mittels -S x) Standby (also Motor aus). Es geht dir ja um diesen Standby-Modus...

      Blowback

      Das erste Datenblatt das ich gefunden habe sagt auch das APM nicht supportet ist. Evtl. kann die Platte einfach keinen sleep, da Enterprise-Gedöns?
      Er hier nutzt noch irgendein Seagate-Tool das ich nicht kenne: https://www.realhardwarereviews.com/seagate-exos-x18-review/6/
      Hab es nicht im Detail gelesen, aber ich denke entweder musst du einfach noch ein wenig rumhacken bis es tut ( 😉 ) oder doch mal exakte Datenblätter durchwühlen ob die Platte das überhaupt kann.

      So spontan hab ich da jetzt auch keine weiteren Einfälle - ausser die ist über eine USB-Bridge angeschlossen, das wäre dann hässlich 😉

      Zunächst einmal danke für die vielen Vorschläge! 🙂

      Über USB ist die HDD nicht angeschlossen, sondern über SATA.

      An irgendwelchen "Diskmanagern" etc. von irgendwelchen Desktop-Managern bzw. überhaupt an externen Vorgängen - die die Platte ggf. wieder aufwecken - kann es nicht liegen?

      Sollte es nicht, da ich sie ja unter zwei unabhängigen Distros getestet habe (Arch und Debian). Zusätzlich auch noch mehrmals formatiert und eben auch kurz unter Windows getestet. Überall das selbe Verhalten.

      Den Output von hdparm -M /dev/sda habe ich in Post#5 geschickt.

      hdparm -B /dev/sda gibt:

      /dev/sda:
       APM_level      = not supported

      smartctl -i -n standby /dev/sda hingegen wird spannend:

      === START OF INFORMATION SECTION ===
      Device Model:     ST18000NM000J-2TV103
      Serial Number:    Z******G
      LU WWN Device Id: 500******b13fd59
      Firmware Version: SN01
      User Capacity:    18,000,207,937,536 bytes [18.0 TB]
      Sector Sizes:     512 bytes logical, 4096 bytes physical
      Rotation Rate:    7200 rpm
      Form Factor:      3.5 inches
      Device is:        Not in smartctl database [for details use: -P showall]
      ATA Version is:   ACS-4 (minor revision not indicated)
      SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
      Local Time is:    Sat Nov 27 16:57:30 2021 CET
      SMART support is: Available - device has SMART capability.
      SMART support is: Enabled
      Power mode is:    ACTIVE or IDLE

      Während hier der Power-Modus zwar ACTIVE or IDLE und nicht STANDBY ist, habe ich auch mal watch probiert.
      Der Modus ändert sich auch hier nicht, aaaber:
      Sobald das smartctl Kommando ausgeführt wird, verschwindet dieses - ich nenne es jetzt mal - minimale Rauschen für einen winzigen Augenblick. (Ist wie bereits beschrieben nicht wirklich ein Kratzen; schwer zu beschreiben ...)

      Ganau dieses Rauschen ist meiner Theorie nach ja der Grund (nämlich die minimale Aktivität), welcher den gewünschten Standby bei Inaktivität verhindert.
      Also dachte ich mir, ich führe mal watch -n 0.1 sudo smartctl -i -n idle /dev/sda aus, und siehe da. Das Rauschen verschwindet vollständig und ich höre nurnoch das für HDDs normale "Piepen", welches durch die Rotation entsteht.
      Führe ich jetzt - während watch -n 0.1 sudo smartctl -i -n idle /dev/sda im einen Fester läuft - hdparm -S 1 /dev/sda in einem anderen Terminal-Fenster aus, fährt die HDD innerhalb von 5 Sekunden vollständig herunter und im smartctl-Fenster erscheint: Device is in STANDBY mode, exit(2)!

      Mir absolut unerklärbar 😮

      Edit: Ich kann mir nicht erklären wie wir das jetzt gemacht haben - zumal ich im Grunde nur die im Thread geposteten Kommandos eingesetzt habe, jedenfalls verhällt sich die Festplatte jetzt so, dass sie sich - sofern nicht von anderen Prozessen benutzt - bei jedem belibigen smartctl-Kommando - z.B. smartctl -i /dev/sda herunterfährt!

      • GerBra hat auf diesen Beitrag geantwortet.

        Update: Dieses seltsame Verhalten ist nun nicht mehr zu beobachten, sprich während sie gemounted ist, hört man nur die Rotation und kein konstantes Rauschen, und sobald ich die HDD umounte fährt sie sich auch innerhalb von wenigen Sekunden herunter 😃

        Einziges Problem nurnoch: Obwohl in hdparm einen Timer von fünf Sekunden eingestellt, fährt die HDD, wenn sie eingebunden ist (z.B. unter /mnt/myhdd/) jedoch nicht benutzt wird, nicht herunter (ich befinde mich auch nicht in /mnt/myhdd/).

        iostat -d 1 sda1 zeigt mir auch minimal Schreibvorgänge an:

        Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
        sda1              0.00         0.00         0.00         0.00          0          0          0
        
        
        Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
        sda1              1.00         0.00       512.00         0.00          0        512          0
        
        
        Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
        sda1              0.00         0.00         0.00         0.00          0          0          0
        
        
        Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
        sda1              0.00         0.00         0.00         0.00          0          0          0
        
        
        Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
        sda1              3.00         0.00       524.00         0.00          0        524          0
        
        
        Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
        sda1              0.00         0.00         0.00         0.00          0          0          0
        
        
        Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
        sda1              0.00         0.00         0.00         0.00          0          0          0
        
        
        Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
        sda1              1.00         0.00       512.00         0.00          0        512          0
        
        
        Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
        sda1              0.00         0.00         0.00         0.00          0          0          0
        
        
        Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
        sda1              0.00         0.00         0.00         0.00          0          0          0

        Wenn ich an der HDD fühle kann ich auch (außer der Rotation) alle 1-2 Sekunden eine leichte Vibration spüren.
        Wisst ihr woran das liegen kann oder gibt es evtl. eine Möglichkeit alle Prozesse, die von der HDD lesen bzw. auf sie schreiben wollen zu monitoren?

        • GerBra hat auf diesen Beitrag geantwortet.

          Blowback Mir absolut unerklärbar

          Ich habe auch noch ein wenig getestet, und bin auch auf ein paar Merkwürdigkeiten gestoßen.

          Gewundert hatte mich, daß meine HD im Standby-Modus von selbst quasi nie aufwacht. Außer auf explizite (ungecachte) Lese bzw. auf Schreibvorgänge.
          Ich simuliere Aktivität mit: touch /usr/local/tank/xxx (erzeugt/erneuert die Datei xxx auf meiner HD).
          Allerdings versetzte sich meine geweckte HD danach auch nicht mehr von selbst in den Standby-Modus, egal welche Zeitspanne ich für den Standby-Timer wähle.

          Erst war meine Vermutung der "Desktop", mit allen udisk, gvfs und systemd Geraffel. Also habe ich es ohne Desktop nur als root auf den TTYs getestet. Dort aber das gleiche: Die HD geht nach einer Aktivierung nicht mehr selbständig von Active/Idle in den Standby-Modus.

          Erst dachte ich: Evtl. ist das "hdparm -S x /dev/sdxx" ja ein "Einmal-Kommando" um eben ab sofort die HD nach x Sekunden in den Standby zu schicken wenn sie eben Idle ist. Und nicht eine Anweisung an die Hardware, das über die Firmware selbständig zu tun.

          Aber dann traf ich auf diese Merkwürigkeit, zumindest hier mit meiner HD:
          Ein laufendes
          watch -n 2 smartctl -n standby /dev/sdb
          verhindert bei mir - warum auch immer - das die HD nach x Sekunden wieder in den Standby geht. Dieser watch-Lauf sollte ja eine bequeme Kontrolle sein, wann die HD ihren Zustand von Active/idle zu Standby wechselt. Aber "irgendwas" blockiert bei dieser Nutzung eben den Wechsel.
          Beende ich die watch-Schleife geht die HD sofort nach x in den Standby. Im Standby-Modus kann ich (ohne watch) den smartctl-Befehl so oft wie gewollt "per Hand" starten, die Platte bleibt standby. Selbst die watch-Schleife kann ich wieder starten...

          Also kurz: eine laufende watch/smartctl-Schleife verhindert bei mir den automatischen Standby. Und jetzt hatte ich grad noch eine Idee.... Und voilá!
          ...
          Anmerkungen zum wertvollen Befehl:
          smartctl -n standby /dev/sdX
          a) Dieser Befehl weckt eine im Standby befindliche HD wirklich nicht aus diesem Standby auf, wenn so der momentane Status abgefragt werden soll.
          b) Hingegen (tückisch!) verhindert eine Ausführung dieses Befehls daß die HD automatisch in den Standby-Modus wechselt. Und zwar dann, wenn der Befehl vor dem gewählten Standby-Intervall (z.B. mit hdparm -S 1 also 5 Sekunden) ausgeführt wird. Das war bei der mitlaufenden watch-Schleife ja der Fall. Ebenso wenn man es per Hand absetzt.

          Also diesen Befehl zum Abfragen definitiv erst (weit?) nach dem gewünschten Standby-Intervall absetzten bzw. nach "akustischer Kontrolle".

          Aktuell schaltet sich meine HD eben nach 5 Sekunden in Idle auf Standby(Motor aus). Das dem so ist, kann ich mittels obigem smartctl abfragen. Auf dem Desktop gibt es auch keinen bisher erkennbaren Unterschied zum root-TTY.

          N.B.: Ich bin weder am Desktop noch bei Server ein Freund dieser Standby-Strapazen, wenn ich keine Festplatten will dann baue ich sie aus ;-)

          Interessant ...

          Umso toller wird es, wenn ich jetzt sage, dass bei mir smartctl (auch in einer watch-Schleife) das Versetzen der HDD in Standby mittels hdparm absolut nicht beeinflusst. (Mit der anderen 6TB nicht-NAS HDD getestet)

          • GerBra hat auf diesen Beitrag geantwortet.

            Blowback Umso toller wird es,

            Ja, die spinnen, die Festplatten.... ;-)

            Blowback oder gibt es evtl. eine Möglichkeit alle Prozesse, die von der HDD lesen bzw. auf sie schreiben wollen zu monitoren?

            Ad hoc fällt mir da erstmal lsof ein. Zeigt geöffnete Dateien an.
            Evtl. sowas:
            lsof /dev/sda1
            Kriegst halt die Dateien und PIDs raus.

            ein Jahr später

            Gibt es Neuigkeiten zu diesem Thema?

            • Dirk hat auf diesen Beitrag geantwortet.

              fredolin92 Gibt es Neuigkeiten zu diesem Thema?

              Wenn, dann sicher in einem neuen Thread.

              Dirk hat die Diskussion geschlossen ().