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

fallobst · April 16, 2020 at 7:25 PM

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:

Code

Apr 16 02:32:25 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is in STANDBY mode, suspending checks
Apr 16 03:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is back in ACTIVE or IDLE mode, resuming checks (1 check skipped)
Apr 16 03:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 36 to 50
Apr 16 03:32:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 50 to 42
Apr 16 04:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 42 to 37
Apr 16 05:32:25 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is in STANDBY mode, suspending checks
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)
Apr 16 06:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Prefailure Attribute: 3 Spin_Up_Time changed from 86 to 83
Apr 16 06:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 37 to 54
Apr 16 06:32:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 54 to 42
Apr 16 07:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 42 to 37
Apr 16 08:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 37 to 36
Apr 16 11:32:25 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is in STANDBY mode, suspending checks
Apr 16 12:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is back in ACTIVE or IDLE mode, resuming checks (1 check skipped)
Apr 16 12:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Prefailure Attribute: 3 Spin_Up_Time changed from 83 to 81
Apr 16 12:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 36 to 51
Apr 16 12:32:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 51 to 40

Display More

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

Code

Apr 16 05:32:25 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is in STANDBY mode, suspending checks
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:

Code

Apr 16 13:00:01 vm-host-001 kernel: [71871.622478] lsblk(18758): dirtied inode 35419 (sdc) on sysfs
Apr 16 13:00:01 vm-host-001 kernel: [71871.622514] lsblk(18758): dirtied inode 35391 (sdc) on sysfs
Apr 16 13:00:01 vm-host-001 kernel: [71871.622571] lsblk(18758): dirtied inode 48169 (sdc1) on sysfs
Apr 16 13:00:01 vm-host-001 kernel: [71871.622590] lsblk(18758): dirtied inode 35395 (sdc) on sysfs
Apr 16 14:00:01 vm-host-001 kernel: [75471.883923] lsblk(19468): dirtied inode 35419 (sdc) on sysfs
Apr 16 14:00:01 vm-host-001 kernel: [75471.883960] lsblk(19468): dirtied inode 35391 (sdc) on sysfs
Apr 16 14:00:01 vm-host-001 kernel: [75471.884023] lsblk(19468): dirtied inode 48169 (sdc1) on sysfs
Apr 16 14:00:01 vm-host-001 kernel: [75471.884043] lsblk(19468): dirtied inode 35395 (sdc) on sysfs
Apr 16 15:00:01 vm-host-001 kernel: [79071.865083] lsblk(20118): dirtied inode 35391 (sdc) on sysfs
Apr 16 15:00:01 vm-host-001 kernel: [79071.870732] lsblk(20119): dirtied inode 35419 (sdc) on sysfs
Apr 16 15:00:01 vm-host-001 kernel: [79071.870841] lsblk(20119): dirtied inode 48169 (sdc1) on sysfs
Apr 16 15:00:01 vm-host-001 kernel: [79071.870862] lsblk(20119): dirtied inode 35395 (sdc) on sysfs

Display More

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

Code

Apr 16 16:00:01 vdr-server-001 kernel: [ 2135.181940] lsblk(2168): dirtied inode 20759 (sdd) on sysfs
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?

davie2000 · April 16, 2020 at 8:21 PM

viell hilft das, den Schuldigen zu finden: https://forum.openmediavault.org/index.php/Thre…/?postID=134554

fallobst · April 16, 2020 at 8:51 PM

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.

wirbel · April 17, 2020 at 8:05 AM

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

fallobst · April 17, 2020 at 8:32 AM

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.

wirbel · April 17, 2020 at 8:37 AM

https://www.computerwissen.de/hardware/pc-ti…ueberblick.html

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

wirbel · April 17, 2020 at 8:46 AM

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.

Argus · April 17, 2020 at 9:27 AM

Quote from fallobst

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/de/wiki/SMART_Tests_mit_smartctl

fallobst · April 17, 2020 at 10:49 AM

Quote from wirbel

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

Quote from Argus

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

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.

fallobst · April 17, 2020 at 10:21 PM

Quote from wirbel

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

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?)

Quote from wirbel

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:

Code

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   001    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0004   135   135   054    Old_age   Offline      -       108
  3 Spin_Up_Time            0x0007   083   083   001    Pre-fail  Always       -       314 (Average 387)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       47
  5 Reallocated_Sector_Ct   0x0033   100   100   001    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000a   100   100   001    Old_age   Always       -       0
  8 Seek_Time_Performance   0x0004   133   133   020    Old_age   Offline      -       18
  9 Power_On_Hours          0x0012   100   100   000    Old_age   Always       -       151
 10 Spin_Retry_Count        0x0012   100   100   001    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       21
 22 Unknown_Attribute       0x0023   100   100   025    Pre-fail  Always       -       100
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       52
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       52
194 Temperature_Celsius     0x0002   039   039   000    Old_age   Always       -       40 (Min/Max 13/57)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   100   100   000    Old_age   Always       -       0

Display More

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.

Argus · April 17, 2020 at 10:31 PM

Quote from fallobst

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.

fallobst · April 17, 2020 at 10:59 PM

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.

wirbel · April 17, 2020 at 11:15 PM

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.

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

Participate now!

Tags

Users Viewing This Thread