• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Workaround] 'hdparm -S' funktioniert nicht (PowerManagement)

gehrke

Administrator
Teammitglied
Moin *

Bin frustriert! Ich versuche, meinen Stromverbrauch zu reduzieren, aber gleich bei mehreren Festplatten scheitere ich daran, dass das Powermanagement per hdparm nicht funktioniert.

Vorweg: Ganz grundsätzlich Schlafen legen kann ich alle Festplatten. Dies fährt den Motor hörbar runter und reduziert den Stromverbrauch massiv:
Code:
# hdparm -y /dev/sdd
Code:
# smartctl -i -n standby /dev/sdd
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-193.19.1.el8_2.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

Device is in STANDBY mode, exit(2)
Aber das Setzen eines automatischen Timeouts für das APM inklusive Spindelmotor führt nicht zum gewünschten Ergebnis:
Code:
# /usr/sbin/hdparm -S 1 -B 1 /dev/sdd ; date

/dev/sdd:
 setting Advanced Power Management level to 0x01 (1)
 setting standby to 1 (5 seconds)
 APM_level	= 1
Di 10. Nov 08:32:06 CET 2020
Code:
# date; smartctl -i -n standby /dev/sdd
Di 10. Nov 08:32:56 CET 2020
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-193.19.1.el8_2.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     HGST Ultrastar He8
Device Model:     HGST HUH728080ALE600
Serial Number:    <...>
LU WWN Device Id: 5 000cca 254ceaec4
Firmware Version: A4GNT7J0
User Capacity:    8.001.563.222.016 bytes [8,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Nov 10 08:32:56 2020 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Power mode is:    ACTIVE or IDLE
Ja, mir ist bekannt, dass diese aggressive Parametrisierung nicht gesund ist für die Hardware. Ich habe die kurze Zeitspanne gewählt, um besser Testen zu können.
Ja, ich bin mir relativ sicher, dass in dieser Zeit keine Aktivität auf der Platte stattfindet, die den Timeout verhindert. Und nein, auch nach längerer Wartezeit funktionert das nicht.

Infos zur Festplatte:
Code:
# smartctl -i -c /dev/sdd
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-193.19.1.el8_2.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     HGST Ultrastar He8
Device Model:     HGST HUH728080ALE600
Serial Number:    <...>
LU WWN Device Id: 5 000cca 254ceaec4
Firmware Version: A4GNT7J0
User Capacity:    8.001.563.222.016 bytes [8,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Nov 10 08:39:54 2020 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
General SMART Values:
Offline data collection status:  (0x82)	Offline data collection activity
					was completed without error.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(  101) seconds.
Offline data collection
capabilities: 			 (0x5b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 (1092) minutes.
SCT capabilities: 	       (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.
Ich habe recherchiert und sehr viele Stellen gefunden, in denen ein ähnliches Verhalten beschrieben wird. Scheinbar ist das also ein häufig auftretendes Problem.
Derzeit ist mir unklar, ob es an der Software oder der Hardware liegt.

Glückauf,
gehrke

EDIT: OS ist CentOS 8
 
OP
gehrke

gehrke

Administrator
Teammitglied
Nachtrag zur Info:
Code:
# hdparm -I /dev/sdd

/dev/sdd:

ATA device, with non-removable media
	Model Number:       HGST HUH728080ALE600                    
	Serial Number:      <...>            
	Firmware Revision:  A4GNT7J0
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0; Revision: ATA8-AST T13 Project D1697 Revision 0b
Standards:
	Used: unknown (minor revision code 0x0029) 
	Supported: 9 8 7 6 5 
	Likely used: 9
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: 15628053168
	Logical  Sector size:                   512 bytes
	Physical Sector size:                  4096 bytes
	Logical Sector-0 offset:                  0 bytes
	device size with M = 1024*1024:     7630885 MBytes
	device size with M = 1000*1000:     8001563 MBytes (8001 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 = 0
	Advanced power management level: 1
	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
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	   *	Advanced Power Management feature set
	    	Power-Up In Standby feature set
	   *	SET_FEATURES required to spinup after power up
	    	SET_MAX security extension
	   *	48-bit Address feature set
	   *	Device Configuration Overlay 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
	   *	URG for READ_STREAM[_DMA]_EXT
	   *	URG for WRITE_STREAM[_DMA]_EXT
	   *	WRITE_UNCORRECTABLE_EXT command
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	Segmented DOWNLOAD_MICROCODE
	   *	unknown 119[6]
	    	unknown 119[7]
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Gen3 signaling speed (6.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Host-initiated interface power management
	   *	Phy event counters
	   *	NCQ priority information
	   *	READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
	    	Non-Zero buffer offsets in DMA Setup FIS
	   *	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	    	In-order data delivery
	   *	Software settings preservation
	    	unknown 78[7]
	    	unknown 78[10]
	    	unknown 78[11]
	   *	SMART Command Transport (SCT) feature set
	   *	SCT Write Same (AC2)
	   *	SCT Error Recovery Control (AC3)
	   *	SCT Features Control (AC4)
	   *	SCT Data Tables (AC5)
	   *	SANITIZE feature set
	   *	CRYPTO_SCRAMBLE_EXT command
	   *	OVERWRITE_EXT command
	   *	reserved 69[3]
	   *	reserved 69[4]
	   *	WRITE BUFFER DMA command
	   *	READ BUFFER DMA command
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
	not	frozen
	not	expired: security count
	not	supported: enhanced erase
	930min for SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000cca254ceaec4
	NAA		: 5
	IEEE OUI	: 000cca
	Unique ID	: 254ceaec4
Checksum: correct
 

josef-wien

Ultimate Guru
Es gibt auch einen Weg über udisks (siehe manpage bzw. den letzten Abschnitt von https://petermolnar.net/article/hard-drive-spindown-clicking-noise/).

(Mit praktischen Erfahrungen kann ich nicht dienen, da ich Medien mit rotierenden Scheiben seit vielen Jahren nur für Datensicherungs- und Multimedia-Zwecke verwende.)
 
OP
gehrke

gehrke

Administrator
Teammitglied
josef-wien schrieb:
Es gibt auch einen Weg über udisks (siehe manpage bzw. den letzten Abschnitt von https://petermolnar.net/article/hard-drive-spindown-clicking-noise/).
OK, das deckt sich ja mit meinen Erfahrungen.

udisks2 - Hmm, hab' mal wieder keinen Schimmer. Muss mich erst schlau machen, aber offenbar ist das in irgendeiner Form aktiv auf dem System:

Code:
# udisksctl status 
MODEL                     REVISION  SERIAL               DEVICE
--------------------------------------------------------------------------
TS512GMTE110S                       <...>                nvme0n1 
WDC WD30EZRX-00M          0A80      <...>                sda     
HGST HUH728080AL          T7J0      <...>                sdd


josef-wien schrieb:
(Mit praktischen Erfahrungen kann ich nicht dienen, da ich Medien mit rotierenden Scheiben seit vielen Jahren nur für Datensicherungs- und Multimedia-Zwecke verwende.)
Bin irritiert: Ja, tue ich auch. Und genau da will ich Strom sparen.

However - vielen Dank für den Hinweis.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Ich habe den Eindruck, dass udisks2 auch nur ein Wrapper von systemd ist, welcher letztlich das selbe macht.

Jedenfalls tut sich da bislang ebenfalls nix:
Code:
# cat /etc/udisks2/HGST-HUH728080ALE600-<serial-deleted>.conf 
[ATA]
StandbyTimeout=6
 

josef-wien

Ultimate Guru
gehrke schrieb:
Code:
# udisksctl status
...
HGST HUH728080AL T7J0 <...> sdd
gehrke schrieb:
# cat /etc/udisks2/HGST-HUH728080ALE600-<serial-deleted>.conf
Sobald der Dämon udisksd eine aus seiner Sicht korrekte Datei (oder deren Änderung) erkennt, gibt es eine Eintragung im System-Log. Auch mit
Code:
udisksctl monitor
(als normaler Benutzer) erkennst Du, was sich tut. Laß einmal "E600" weg.

udisks2 hat nichts mit systemd zu tun. In der Praxis besteht die Hauptaufgabe darin, im Auftrag der jeweiligen grafischen Oberfläche externe Medien einzuhängen. Üblicherweise wird der Dämon erst dann von dbus gestartet, wenn eine entsprechende Anforderung kommt (auch der auf der Konsole (als normaler Benutzer) ausgeführte Befehl udisksctl ist eine solche). Wenn es bei Dir funktioniert, mußt Du wohl dafür sorgen, daß er bereits beim Systemstart aktiviert wird.
 
OP
gehrke

gehrke

Administrator
Teammitglied
josef-wien schrieb:
Laß einmal "E600" weg.
Wo kam das her? Von der verlinkten Seite:
Code:
info=$(smartctl -i /dev/sda)
device=$(echo -i "$info" | grep 'Device Model' | cut -d":" -f2 | xargs | sed 's/ /-/m')
serial=$(echo "$info" | grep -i 'Serial Number' | cut -d":" -f2 | xargs | sed 's/ /-/m')

echo -e "[ATA]\nStandbyTimeout=180" > "/etc/udisks2/$device-$serial.conf"
https://petermolnar.net/article/hard-drive-spindown-clicking-noise/

OK, also lasse ich es weg.
Code:
-rw-r--r--. 1 root root 23 10. Nov 18:35 /etc/udisks2/HGST-HUH728080AL-<serial>.conf

# cat /etc/udisks2/HGST-HUH728080AL-<serial>.conf 
[ATA]
StandbyTimeout=6
Und voila:
Code:
Nov 10 18:35:16 j15 udisksd[584899]: Applying configuration from /etc/udisks2/HGST-HUH728080AL-<serial>.conf to /dev/sdd
Nov 10 18:35:24 j15 kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Nov 10 18:35:27 j15 kernel: ata2.00: configured for UDMA/133
Nov 10 18:35:27 j15 udisksd[584899]: Error sending ATA command IDLE (timeout=6) to /dev/sdd: Unexpected sense data returned:
                                     0000: 70 00 05 00  00 00 00 0a  00 40 00 ff  21 04 00 00    p........@..!...
                                     0010: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
                                      (g-io-error-quark, 0)
Code:
# udisksctl monitor
Monitoring the udisks daemon. Press Ctrl+C to exit.
18:36:25.913: The udisks-daemon is running (name-owner :1.10046).
18:46:00.846: /org/freedesktop/UDisks2/drives/HGST_HUH728080AL_<serial> org.freedesktop.UDisks2.Drive.Ata: Properties Changed
  SmartPowerOnSeconds:          56689200
  SmartTemperature:             306.15000000000003
  SmartUpdated:                 1605030360
So ganz habe ich es bislang noch nicht verstanden, aber um ca. 18:55 wurde die Festplatte schlafen gelegt!
 
Schwierig zu helfen ...

Die Sache funktioniert ca. so:
Auf der Print der HD befindet sich ein Controller, der sein eigenes "BIOS" läuft.
Der kann in Richtung motherboard SATA und in die andere Richtung steuert er die Platte.
hdparm kann mit diesem Controller kommunizieren, z.B.
"Setze deinen timer auf x und schalte die Platte ab, wenn du nichts zu tun hast"
hdparm tut sein Bestes aber, .. kann der Controller das? Unterstützt er das?
"Ich kann das nicht" gibt er an hdparm NICHT zurück und so erfährt man auch nichts.
Das Ab- und Einschalten des Motors muß er als Grundfunktion sowieso können,
deshalb ist das kein Hinweis darauf, dass er den timer auch kann.

Was tun wenn sich nichts tut?
Dann muß man das extern lösen. Dafür braucht es in jedem Fall einen daemon, der 1. den timer kann und 2. über
den Datentraffic Bescheid weiß. Eignen tut sich dafür der daemon udevd aber auch ein simpler cron job könnte das Problem lösen.
z.B. mit einem 1 Sekunden job: mit (iostat,dstat,.. oder ähnlich) den traffic messen, den timer decrementieren und mit
hdparm ab/einschalten, sofern das Einschalten bei traffic der Controller nicht selbst erledigt. 5 Zeilen script sollten dafür ausreichen.
Du wärst damit unabhängig von der Hardware und kannst z.B, deine Platten am 24.Dezember um 18:12 in Abständen von
6 Sek. zum Schlafen schicken (oder was auch immer)

Gruß
Gräfin Klara
 

josef-wien

Ultimate Guru
Bei mir haben die Befehle genau das geliefert, was auch der udisksctl-Status von sich gegeben hat. Und es gibt eben Controller, die zwar Fehlermeldungen produzieren, aber trotzdem brav das tun, was von Ihnen gewünscht wurde.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Tja, zuletzt hat das automatische Schlafenlegen hier ja tatsächlich auch funktioniert und die Platte ist über Nacht auch nicht wieder angesprungen.
Aber die Abschaltung nicht in den Zeiten, die ich erwartet hatte. Ich arbeite noch daran, ein Muster herauszufinden, um es besser zu verstehen.

Um 9:30 laufen wieder Backup-Jobs los, dann sollten die Platten on demand wieder gestartet werden und sich danach hoffentlich wieder automatisch abschalten. Und zwar bei der aktuellen Parametrisierung eine halbe Minute (6 * 5 Sekunden) nach dem Ende des letzten Backup-Jobs:
Code:
StandbyTimeout=6
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
josef-wien schrieb:
Laß einmal "E600" weg.
Wo kam das her? Von der verlinkten Seite:
Code:
info=$(smartctl -i /dev/sda)
device=$(echo -i "$info" | grep 'Device Model' | cut -d":" -f2 | xargs | sed 's/ /-/m')
serial=$(echo "$info" | grep -i 'Serial Number' | cut -d":" -f2 | xargs | sed 's/ /-/m')

echo -e "[ATA]\nStandbyTimeout=180" > "/etc/udisks2/$device-$serial.conf"
https://petermolnar.net/article/hard-drive-spindown-clicking-noise/

OK, also lasse ich es weg.
Das Script ist fehlerhaft, auch bei der anderen Festplatte führte es zu einer falsch benannten Config.
Wenn man sich manuell an die Werte hält, die udisksctl ausgibt, dann klappt es auch mit der Aktivierung des Dienstes, erkennbar an der sofortigen Statusmeldung im Journal.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Das scheint geklappt zu haben, beide Festplatten sind nach Durchführung der Jobs wieder in standby.

Also verwende ich jetzt mal sinnvollere Konfigurationsparameter, die zu meinem speziellen Anwendungsfall passen:
Code:
StandbyTimeout=241
Dauer: 30 Minuten (mehrere Clients)
Code:
StandbyTimeout=120
Dauer: 10 Minuten (es gibt nur einen einzigen Client, der maximal einmal am Tag läuft)

Um das langfristig kontrollieren zu können, protokolliere ich die Stati minütlich:
Code:
# crontab -l
* * * * * date >> /var/log/disks-standby.log ; /usr/sbin/smartctl -i -n standby /dev/sda | egrep 'Power mode is|Device is in STANDBY mode' >> /var/log/disks-standby.log ; /usr/sbin/smartctl -i -n standby /dev/sdd | egrep 'Power mode is|Device is in STANDBY mode' >> /var/log/disks-standby.log
 
OP
gehrke

gehrke

Administrator
Teammitglied
Tja, die ersten Tests zeigen ein vollkommen unerwartetes Bild.

Vorgehensweise:
*Sicherstellen, dass Platte im 'standby'
*via 'ls' eine Aktivität anstossen und Timestamp protokollieren, woraufhin die Platte erwacht und die Inhalte des Verzeichnisses anzeigt
*Warten, bis die Platte wieder in 'standby' fährt.

Disk 1 - StandbyTimeout=241:
ls: Mi 11. Nov 12:45:56 CET 2020
Standby laut Log: Mi 11. Nov 12:48:01 CET 2020

Disk 2 - StandbyTimeout=120
ls: Mi 11. Nov 12:00:59 CET 2020
Standby laut Log: <bislang noch nicht erreicht (12:58), weiterhin aktiv>

Die eine Platte fährt viel zu früh runter, die andere gar nicht. :zensur:
 

Christina

Moderator
Teammitglied
Ich probiere gerade als "StandbyTimeout=108" (hdparm -S 108):
Code:
 setting Advanced Power Management level to 0x80 (128)
 setting standby to 108 (9 minutes)
 APM_level	= 128
Es dauert aber meistens länger als 9 Minuten, bis die HDD wieder abschaltet;
also z.B. 13 min, 15 min und nach dem Aufwachen aus Suspend-to-RAM sogar 28 min.

Welchen Einfluss hat eigentlich APM_level hier noch? Das habe ich noch nicht herausgefunden.
Per udisks ist das in der conf-Datei "APMLevel=128" (hdparm -B 128).

lg Christina
 
OP
gehrke

gehrke

Administrator
Teammitglied
Bekommst Du beim Setzen des Parameters denn auch einen Error wie hier?:
Code:
Nov 10 18:35:27 j15 udisksd[584899]: Error sending ATA command IDLE (timeout=6) to /dev/sdd: Unexpected sense data returned:
                                     0000: 70 00 05 00  00 00 00 0a  00 40 00 ff  21 04 00 00    p........@..!...
                                     0010: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
                                      (g-io-error-quark, 0)

Code:
Nov 12 11:30:28 j15 udisksd[584899]: Error sending ATA command IDLE (timeout=1000) to /dev/sdd: Unexpected sense data returned:
                                     0000: 70 00 05 00  00 00 00 0a  00 40 00 01  21 04 00 00    p........@..!...
                                     0010: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00    ................
                                      (g-io-error-quark, 0)
Ich habe unterdessen höhere Timeouts ausprobiert, aber das hat scheinbar gar keinen Einfluss. Ich befürchte, dass die Platte meine Werte missversteht.
 

josef-wien

Ultimate Guru
Christina schrieb:
Advanced Power Management level
Auch hier kommt es darauf an, was die Platte unterstützt und was sie daraus macht. Platten sind schon sehr, sehr lange eigenständige Computer mit eigenem Prozessor und eigenem Betriebssystem (üblicherweise firmware genannt). Das Betriebssystem des PC kann Ansuchen an die Platte stellen, was und wie sie es tut, entscheidet sie selbst.

Zumindest bei Western Digital- und damit auch bei Hitachi-Platten werden die Schreib-/Leseköpfe standardmäßig nach 8 Sekunden geparkt. Das reduziert den Luftwiderstand und somit minimal den Stromverbrauch, reduziert aber die Lebenszeit, wenn es ständig passiert. Bei manchen Platten kann ich das mit "hdparm -J n" beeinflussen, manche akzeptieren das aber nicht mehr, und dann muß ich zu "hdparm -B 254" greifen, wenn ich das deaktivieren will (was ich beim Anschluß am PC so handhabe, während ich das Parken beim Anschluß am Multimedia-Player für sinnvoll erachte).
 

Christina

Moderator
Teammitglied
@gehrke
Nein, ich finde keine solche Fehlermeldung im journal (6 Monate), wenn ich nach "sending ATA command" oder "Unexpected sense data" suche. -> Pattern not found (press RETURN)

@josef-wien
Manpage: hdparm -B {128…255} do not permit spin-down.
Hat hdparm -B vom Prinzip keine Auswirkungen/Nebenwirkungen auf hdparm -S?

P.S. Ich verwende hdparm -S 72 für den spin-down schon seit Leap 15.1, aber einen direkten Einfluss von hdparm -B 127 / 128 konnte ich bei mir (Seagate ST1000) nicht feststellen. Jedoch bei hdparm -S 120 oder höher will die HDD unter Leap gar nicht mehr zuverlässig abschalten!

lg Christina
 
OP
gehrke

gehrke

Administrator
Teammitglied
Nach 2 Wochen Produktivbetrieb kann ich nur ein durchwachsenes Fazit ziehen. Es funktioniert leider nicht zuverlässig.

Zu einem großen Anteil (circa 70 bis 90 Prozent) schalten die Platten sich wie gewünscht ab. Nicht in der von mir gedachten Zeit, aber sie tun es.
Sporadisch wachen sie auf, ohne dass mir klar ist, warum das so ist.
Manchmal schalten sie sich schlicht gar nicht ab, und ich muss das manuell triggern. Dann bleiben sie auch aus.

Ich habe hierzu noch kein Muster herausfinden können.

Zum Monatwechsel werden beide Platten getauscht und offline gelagert. Möglicherweise ergibt sich bei den Ersatzplatten ein anderes Bild, was mich hier weiter bringt.
 
Oben