Festplatte wacht immer wieder auf: lsblk(2168): dirtied inode * (sdX) on sysfs

  • Servus!


    Ich möchte meine Festplatte gerne außerhalb der Fernsehzeiten schlafen legen, die wacht aber leider immer wieder auf.

    Die VDR ist eine Ubuntu 20.04 Qemu-VM, die die Festplatte entweder direkt durchgereicht hat (dann läuft das Stromsparen über den Host) oder gleich einen ganzen SATA-Controller bekommt, wobei die Stromsparmechanismen dann über die VM laufen.

    Das Stromsparen läuft über hd-idle, da die Festplatte hdparm -S nicht zu unterstützen scheint, hdparm -Y schon (HDD stammt aus einer WD Element)


    In der VM geben die Logs für die Festplatte folgendes aus:

    wobei mich vor allem Zeilen wie diese (halbstündiger Schlaf) stutzig machen, da zu der Zeit keine Aufnahmen liefen:

    Code
    1. Apr 16 05:32:25 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is in STANDBY mode, suspending checks
    2. Apr 16 06:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is back in ACTIVE or IDLE mode, resuming checks (1 check skipped)


    Nun habe ich mit "echo 1 > /proc/sys/vm/block_dump" das Überwachen der Festplattenzugriffe gestartet.

    Das sieht auf dem Host (Debian 9) so aus:

    Auf der VDR (dann mit durchgereichtem SATA-Controller) sieht das so aus:

    Code
    1. Apr 16 16:00:01 vdr-server-001 kernel: [ 2135.181940] lsblk(2168): dirtied inode 20759 (sdd) on sysfs
    2. Apr 16 16:00:01 vdr-server-001 kernel: [ 2135.182037] lsblk(2168): dirtied inode 20790 (sdd1) on sysfs



    Mich irritiert dieser regelmäßige stündliche Zugriff auf beiden System. Kann sich da jemand einen Reim drauf machen?

    Meine VDR:
    VDR-Server: 2x DVBSKy S952 Dual DVB-S/S2 PCIe + 14TB WD White-Label als VM-Guest mit PCIe-Passthrogh auf einem Ryzen7 VM-Host (virtualisiertes OS: Ubuntu 20.04)
    VDR-Client1: Asrock AB350 Gaming K4 | AMD Ryzen 3 2200G | Linux Mint Mate Mate + Kodi + VDR-VNSI | Pulse Eight CEC USB
    VDR-ClientN: VLC über Streamdev, nicht bloß aufs lokale Netzwerk beschränkt


    Mediathekview/VDR-Aufnahmen nach Staffeln usw. sortieren

  • viell hilft das, den Schuldigen zu finden: https://forum.openmediavault.o…k-Spin-ups/?postID=134554

    MyVDR: yaVDR-Ansible (Ubuntu 18) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Das Script (ich muss es nachher mal testen, laufen gerade Aufnahmen) dürfte ein Problem haben:

    Die Platte wacht auf, nachdem man hdparm -C benutzt hat.


    Edit:

    Das Script scheint trotzdem zu funktionieren, mal gucken, was 22:00 passiert.

    Meine VDR:
    VDR-Server: 2x DVBSKy S952 Dual DVB-S/S2 PCIe + 14TB WD White-Label als VM-Guest mit PCIe-Passthrogh auf einem Ryzen7 VM-Host (virtualisiertes OS: Ubuntu 20.04)
    VDR-Client1: Asrock AB350 Gaming K4 | AMD Ryzen 3 2200G | Linux Mint Mate Mate + Kodi + VDR-VNSI | Pulse Eight CEC USB
    VDR-ClientN: VLC über Streamdev, nicht bloß aufs lokale Netzwerk beschränkt


    Mediathekview/VDR-Aufnahmen nach Staffeln usw. sortieren

    The post was edited 1 time, last by fallobst ().

  • SMART Prefailure Attribute: 3 Spin_Up_Time changed from 86 to 83

    SMART Prefailure Attribute: 3 Spin_Up_Time changed from 83 to 81


    Oh, du möchtest mal ganz fix ein Backup machen.

    /dev/sdc

  • Sicher? Die Platte ist brandneu, sollte ich nicht erstmal 'ne Weile warten, wie die sich einlebt?

    Viel verlieren kann ich nicht, bis auf die Aufnahmen der letzten Tage ist noch alles auf der alten Platte.

    Meine VDR:
    VDR-Server: 2x DVBSKy S952 Dual DVB-S/S2 PCIe + 14TB WD White-Label als VM-Guest mit PCIe-Passthrogh auf einem Ryzen7 VM-Host (virtualisiertes OS: Ubuntu 20.04)
    VDR-Client1: Asrock AB350 Gaming K4 | AMD Ryzen 3 2200G | Linux Mint Mate Mate + Kodi + VDR-VNSI | Pulse Eight CEC USB
    VDR-ClientN: VLC über Streamdev, nicht bloß aufs lokale Netzwerk beschränkt


    Mediathekview/VDR-Aufnahmen nach Staffeln usw. sortieren

  • https://www.computerwissen.de/…ameter-im-ueberblick.html


    Auf jeden Fall würde ich mal die SMART Werte anzeigen lassen und über diesen Parameter nachlesen.

  • Normal braucht ne Platte länger bis zum Hochlaufen, wenn

    - das NT zu schwach ist für den Anlaufstrom der Platte (heute eher nicht mehr..)

    -ein Lagerschaden sich ankündigt

    -der Kopf aufgesetzt hat, z.B. kurzer harter Stoß während die Platte lief.

    -unsachgemäße Behandlung während Transport oder Einbau, wenn der Kopf nicht in Parkposition war, z.b. nach power cut


    Wenn der Kopf aufgesetzt haben sollte, siehst du auch defekte Blöcke.

  • sollte ich nicht erstmal 'ne Weile warten, wie die sich einlebt?

    fallen die Spin-Up Werte kontinuierlich weiter in den Keller, oder steigen sie auch wieder über die Zeit?

    Ich habe hier auch so eine alte WD Platte extern über USB, smartd meldet dort auch hin und wieder fallende Spin-Up Werte. Über den Zeitraum steigen die aber auch wieder . Ausfälle gibt es hier nicht. Ich vermute bei mir, das es an dem schwachen Stecker-NT liegt. Wenn es dann im Raum noch kühl ist (Heizung Nachtmodus) scheinen die Lager sehr zählebig zu sein.

    aber mache mal ruhig einen Smart-Test über die smartmontools --> https://www.thomas-krenn.com/d…/SMART_Tests_mit_smartctl

  • Auf jeden Fall würde ich mal die SMART Werte anzeigen lassen und über diesen Parameter nachlesen.

    Werde ich nachher nochmal machen, momentan schläft sie zum Glück. Zuletzt (gestern) sah alles gut aus


    Ich habe hier auch so eine alte WD Platte extern über USB, smartd meldet dort auch hin und wieder fallende Spin-Up Werte.

    [...]

    Wenn es dann im Raum noch kühl ist (Heizung Nachtmodus) scheinen die Lager sehr zählebig zu sein.

    Das ist eine WD Elements, die ich von ihrem Gehäuse "befreit" habe. Zuletzt war die ordentlich unter Dauerlast, erst zum Testen (noch im Gehäuse), dann zum Übertragen der Aufnahmen. Gestern kamen dann zusätzlich Experimente wegen der Schlafmodi hinzu (wurde oft schlafengelegt), außerdem ist die Platte in einen Wechselrahmen im Keller gelandet, wo die Temperatur anderes sein dürfte, gerade wenn die Platte länger geschlafen hat.

    SmartD habe ich übrigens deaktiviert und bisher schläft die Platte brav (momentan über das Testscript von davie2000).


    Das automatische Schlafenlegen über hd-idle funktioniert auch, laut dem Script wurde sie heute Nacht wegen einer Aufnahme geweckt (was auch so ein sollte), schlief heute Morgen aber wieder. Ich lasse jetzt aber trotzdem nochmal das Script laufen, um die Situation weiter zu beobachten.


    Meldungen wie diese:

    Code
    1. Apr 16 13:00:01 vm-host-001 kernel: [71871.622478] lsblk(18758): dirtied inode 35419 (sdc) on sysfs

    sind übrigens nicht der Grund fürs Aufwachen, die sind auch aufgetaucht, während das Testscript lief und die Platten weiterhin geschlafen haben.

    Meine VDR:
    VDR-Server: 2x DVBSKy S952 Dual DVB-S/S2 PCIe + 14TB WD White-Label als VM-Guest mit PCIe-Passthrogh auf einem Ryzen7 VM-Host (virtualisiertes OS: Ubuntu 20.04)
    VDR-Client1: Asrock AB350 Gaming K4 | AMD Ryzen 3 2200G | Linux Mint Mate Mate + Kodi + VDR-VNSI | Pulse Eight CEC USB
    VDR-ClientN: VLC über Streamdev, nicht bloß aufs lokale Netzwerk beschränkt


    Mediathekview/VDR-Aufnahmen nach Staffeln usw. sortieren

  • SMART Prefailure Attribute: 3 Spin_Up_Time changed from 86 to 83

    SMART Prefailure Attribute: 3 Spin_Up_Time changed from 83 to 81

    Jetzt ist sie wieder bei 83:

    Code
    1. 3 Spin_Up_Time 0x0007 083 083 001 Pre-fail Always - 314 (Average 387)

    (wobei worst so nicht hinhaut🤔, müsste doch 81 sein, oder?)



    https://www.computerwissen.de/…ameter-im-ueberblick.html


    Auf jeden Fall würde ich mal die SMART Werte anzeigen lassen und über diesen Parameter nachlesen.

    Das habe ich jetzt auch mal gemacht und denke, dass ich heute Nacht beruhigt schlafengehen kann:

    Ich hab' mir noch kurz was gescriptet, das mir das Schlafverhalten aufzeichnen sollte. Mal gucken, wie es morgen aussieht.

    Inzwischen sieht's gut aus, die Platte hatte einen ruhigen Tag.

    Meine VDR:
    VDR-Server: 2x DVBSKy S952 Dual DVB-S/S2 PCIe + 14TB WD White-Label als VM-Guest mit PCIe-Passthrogh auf einem Ryzen7 VM-Host (virtualisiertes OS: Ubuntu 20.04)
    VDR-Client1: Asrock AB350 Gaming K4 | AMD Ryzen 3 2200G | Linux Mint Mate Mate + Kodi + VDR-VNSI | Pulse Eight CEC USB
    VDR-ClientN: VLC über Streamdev, nicht bloß aufs lokale Netzwerk beschränkt


    Mediathekview/VDR-Aufnahmen nach Staffeln usw. sortieren

  • Das ist eine WD Elements,

    meine auch, von der ich hier spreche.

    Ich habe da eben noch mal mit smartctl drüber geschaut und will mal meine Werte erläutern. Erwähnenswert ist die Zeile 3. Normalisierter Wert ist 157 , schlechtester ist momentan 155. Ich bin aber der Meinung, das der auch schon mal tiefer lag. RAW Wert ist 7141, das heißt nach 7141 Millisekunden ist die HDD vollständig hochgelaufen. Ich gehe davon aus, das Spin-Up Time auch mal bei 200 lag, jedoch sind die momentanen Werte von 155 noch sehr weit vom Threshold 21 weg, sodass hier wohl noch kein Problem besteht.



  • Ich bin mir nicht sicher, wie gut die Vergleiche passen (Helium 14TB), aber besorgniserregend sollte das bei mir alles nicht sein, wenn ich nicht vollkommen auf dem Schlauch stehe.

    Meine VDR:
    VDR-Server: 2x DVBSKy S952 Dual DVB-S/S2 PCIe + 14TB WD White-Label als VM-Guest mit PCIe-Passthrogh auf einem Ryzen7 VM-Host (virtualisiertes OS: Ubuntu 20.04)
    VDR-Client1: Asrock AB350 Gaming K4 | AMD Ryzen 3 2200G | Linux Mint Mate Mate + Kodi + VDR-VNSI | Pulse Eight CEC USB
    VDR-ClientN: VLC über Streamdev, nicht bloß aufs lokale Netzwerk beschränkt


    Mediathekview/VDR-Aufnahmen nach Staffeln usw. sortieren

  • Reallocated_Sector_Ct und Seek_Error_Rate sehen perfekt aus, die Platte sollte danach in sehr gutem Zustand sein.


    Trotz der Meldungen mit spin_up, diesen Wert einfach mal eine Weile im Auge behalten und danach als bekannte Macke dieser Platte abhaken.

    Merkwürdig anyway - sollte nicht so sein.