Ich bin gerade dabei einen Rechner mit einem Mix aus Solid-State-Disk (aka SSD) und normaler Festplatte aufzubauen. Der Vorteil der SSD ist natürlich die enorme Geschwindigkeit und der lautlose Betrieb. Allerdings ist der Preis pro GB Speicherkapazität leider ebenso enorm… Um trotzdem ausreichend Speicherplatz im Rechner zu haben, wird daher zusätzlich eine herkömmliche Festplatte verbaut. Leider wird der durch die SSD fast lautlose PC durch die Harddisk wieder deutlich lauter. Mit den passenden Einstellungen kann man jedoch die Platte bei Nichtgebrauch via hdparm automatisch abschalten lassen. Für mich eine gute Lösung um die Musik- oder Videosammlung auszulagern oder große Images von virtuellen Maschinen zu speichern…
Im Endeffekt ist das Ganze relativ leicht umzusetzen. Erfahrenen Linux-Usern müsste ich nur die Schlagworte hdparm, die Option -S XX und die Konfigurationsdatei hdparm.conf nennen. Wer ausführliche Informationen möchte, der sollte einfach weiterlesen
Erstmal muss man dazu die Daten der Platte herausfinden, die man bei Nichtgebrauch abschalten möchte. Am einfachsten geht dies über die Laufwerksverwaltung von GNOME, die Ihr über das Menü unter “Einstellungen -> System” aufrufen könnt. Dort müsstet Ihr einfach nur eure Platte raussuchen und euch das entsprechende Gerät “/dev/sdXY” merken.
In meinem Beispiel arbeite ich also mit der Platte /dev/sdc. Wahrscheinlich handelt es sich bei euch um ein anderes Gerät, von daher müsst Ihr die folgenden Hinweise von daher an eure Situation anpassen. Für KDEler gibt es alternativ sicherlich auch in der KDE SC ein entsprechendes Werkzeug und wenn alle Stricke reißen, hilft auf jeden Fall ein sudo fdisk -l weiter.
Nun überprüft Ihr am besten erst einmal, ob sich eure Platte überhaupt in den Leerlauf schicken lässt. Alle halbwegs aktuellen Platten und Controller sollten dazu eigentlich in der Lage sein, aber bevor Ihr euch später wundert warum das nicht funktioniert, solltet Ihr erstmal einen kleinen Test machen. Ruft dazu hdparm mit der Option -C auf…
$ sudo hdparm -C /dev/sdc /dev/sdc: drive state is: active/idle
Man sieht, dass hdparm den Status korrekt abrufen konnte und die Platte läuft, man sollte dies auch an ihrem Betriebsgeräusch erkennen können. Nun könnt Ihr die Platte einmal von Hand abschalten…
$ sudo hdparm -y /dev/sdc
…der Erfolg der Aktion sollte hörbar sein. Optional könnt Ihr erneut mit der Option -C nachprüfen, ob die Platte auch wirklich in den Standby geschickt werden konnte.
$ sudo hdparm -C /dev/sdc /dev/sdc: drive state is: standby
Sobald ihr wieder auf die Platte zugreift (bspw. über den Dateimanager), wird die Platte wieder automatisch anlaufen und ihre Daten preisgeben. Nun wäre es recht umständlich die Platte immer von Hand abzuschalten, besser wäre es, wenn sich die Platte nach einer Gewissen Zeit ohne Zugriffe automatisch abstellen könnte.
Dazu gibt es die Option -S XX von hdparm. Über sie könnt ihr eine Zeitspanne definieren, ab der die Platte abgeschaltet wird. Der Zahlenwert hinter dem Schlüssel drückt nicht direkt die Zeit aus, sondern dient nur als Multiplikator. Ich zitiere einfach mal die man-Page…
Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 minutes plus 15 seconds. Note that some older drives may have very different interpretations of these values.
Ein Wert von bspw. 60 entspricht daher 60*5s, also 300s oder fünf Minuten. Zu kurz sollte man das Timeout nicht wählen, da zu häufiges Runter- und wieder Hochdrehen des Motors die Lebensdauer der Platte beeinträchtigen kann.
$ sudo hdparm -S 60 /dev/sdc
Damit das Ganze automatisch beim Start des Systems ausgeführt wird, solltet Ihr diese Einstellung in der Konfigurationsdatei /etc/hdparm.conf speichern. Am besten arbeitet Ihr in dem Fall mit UUIDs, so dass sich der Eintrag immer auf die gewünschte Platte bezieht, selbst wenn sich eure Plattenkonfiguration einmal ändern sollte. Bestimmt die UUID über bspw…
$ sudo blkid [...] /dev/sdb1: LABEL="data-intern" UUID="ff7f1cdd-431a-4e47-8b90-49737cec82b3" TYPE="ext4" /dev/sdc1: LABEL="datengrab" UUID="4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe" TYPE="ext3"
…und fügt dann einfach euren gewünschten Eintrag an das Ende der hdparm.conf an…
$ sudo gedit /etc/hdparm.conf
[...]
/dev/disk/by-uuid/4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe {
spindown_time = 60
}
…ab dem nächsten Neustart sollte die Einstellung automatisch aktiv sein und eure Platte bei Nichtgebrauch abgeschaltet werden.
Abschließend noch der Hinweis, dass Ihr beim Arbeiten mit hdparm wirklich euer Hirn einschalten müsst. Bei der “Schlaffunktion” müsst Ihr wie bereits erwähnt überdenken, dass zu häufiges Hochdrehen der Platte die Lebensdauer reduzieren kann. Setzt das Intervall daher auf keinen Fall zu kurz.
[UPDATE 13.07.2012: Ich habe den Beitrag auf die aktuelle Syntax der hdparm.conf umgestellt, damit dürften einige Rückfragen aus den Kommentaren geklärt sein.]


14. April 2011 um 13:34 Uhr
Oha oha deine SSD mit ext4. Ich hoffe, du hast das Journal ausgeschaltet?
14. April 2011 um 13:54 Uhr
Die mit ext4 formatierte Platte ist ja eine herkömmliche Harddisk. Bei der SSD ist alles möglichst optimal eingerichtet, muss dazu wohl auch mal einen Beitrag bringen
14. April 2011 um 16:59 Uhr
Bei den neueren Generationen von SSDs mit garabage collection und Trim kann man imho bedenkenlos ext4 einsetzen, da die Funktionen die write amplification minimieren. Und durch ext4 Features wie extents, delayed allocation und Raid stripe-alignment sehe ich keinen Grund mehr das Journal abzuschalten zu müssen.
Just my 2 ¢.
14. April 2011 um 17:21 Uhr
Nachtrag:
@Christoph:
Laut deinem Screenshot scheinst Du stolzer Besitzer einer Crucial RealSSD C300 128 GB zu sein. Mich würde interessieren, welche Lese- und Schreibgeschwindigkeiten Du erreichst.
14. April 2011 um 17:35 Uhr
hi,
du willst sdc schlafen legen, hast aber:
/dev/sdb {
hdparm -S 60 /dev/disk/by-uuid/4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe
in die hdparm.conf eigetragen, die UUID stimmt, aber /dev/sdb ist doch dann falsch, oder?
Wenn ich mehrere Partitionen auf einer Platte habe, hat auch jede Partition ne andere UUID, aber man kann ja nur ganze Platten schlafen legen, also is es vermutlich Wurscht welche UUID ich da eingebe, oder?
13. Juli 2012 um 14:50 Uhr
nicht ganz. Der Fehler im Beispiel ist, dass es nicht:
/dev/sdb {hdparm -S 60 /dev/disk/by-uuid/4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe
}
sondern:
command_line {
hdparm -S 60 /dev/disk/by-uuid/4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe
}
heißen muss – dann klappt’s auch mit dem Nachbarn und dem schlafen gehen (der Platte) …
15. April 2011 um 13:00 Uhr
Hat jemand Erfahrung wie das mit Software RAID funktioniert? Gibts dabei unterschiede, oder muss man einfach alle im RAID Verbund laufende Platten gleichzeitig schlafenlegen und wieder aufwecken?
15. April 2011 um 17:01 Uhr
Hallo,
vielen Dank für Deinen Artikel! Ich möchte den manuellen Befehl nutzen, um meine externe Platte nach einem Backup wieder herunterzufahren. Ist das ok, oder sollte man das lassen? Vielen Dank!
Gruß
15. April 2011 um 17:03 Uhr
Klar, das geht das in Ordnung. Allerdings würde ich dann auch mit der UUID arbeiten, hab schon zu oft die Device-Angaben bzgl. /dev/sdXY sich ändern sehen. Du kannst dich dabei an dem hdparm.conf Eintrag orientieren, vom Syntax ist der ja identisch wie der Aufruf von hdparm.
16. April 2011 um 01:27 Uhr
Lustig..
Das selbe habe ich letzte Woche mit einem Init Startup gelöst
16. April 2011 um 11:00 Uhr
Hallo,
ich arbeite mit udev Regeln. D.h. wenn ich die HD anschließe, dann wird diese automatisch entschlüsselt, gemounted und ein Backup wird durchgeführt. Anschließend, wie gesagt, wird diese dann heruntergefahren. Meine Systemeinstellungen werde ich noch genauer in einem Artikel veröffentlichen.
Gruß
Pingback: Links der Woche – KW15 » Nikonierer
17. April 2011 um 12:01 Uhr
Cooler Artikel,
ich habe damit jetzt meine Festplatte, auf der nur Programme & Spiele für mein Windows-System liegen (ja, manchmal muss ich auch das noch benutzen), jetzt unter Linux in den Dauerschlaf geschickt, da ich die Platte da eh nie lese oder beschreibe
Evtl. hilft mir dein Artikel auch noch für meine externe Festplatte
17. April 2011 um 14:42 Uhr
Hallo,
ich bin mir jetzt nicht sicher, ob du, Felix, mich meinst. Jedenfalls habe ich meinen Artikel zum automatisierten Backup veröffentlicht.
Siehe https://dsiw.wordpress.com/2011/04/17/automatisierte-entschlusselung-der-ext-festplatte-und-backup/
Gruß
18. April 2011 um 15:33 Uhr
Falls die Platte mit “hdparm -y” oder “hdparm -C” nicht in den standby geht mit “hdparm -B” den APM-Level checken.
Manche Platten gehen nur in den Standby wenn der APM-Level kleiner 128 gesetzt wird.
22. April 2011 um 15:05 Uhr
In welchem Verhältnis stehen eigentlich die Einstellungen in der Energieverwaltung von Ubuntu und das hier beschriebene Vorgehen mit Hdparm? Anders gefragt: Wird das Vorgehen über Hdparm obsolet, wenn ich bei den Einstellungen das Häkchen bei “Wenn möglich, Festplatten herunterfahren” gesetzt habe? Oder ist da noch was rauszuholen?
Ach ja: Vielen Dank für diesen und die vielen anderen tollen Artikel!
22. April 2011 um 16:13 Uhr
Bei mir hat die Einstellung bzgl dem herunterfahren der Platten in der Energieverwaltung von Gnome gar nicht funktioniert. Auf meinem Laptop funktionieren sie, aber nicht auf meinem Desktop. Daher der Weg über hdparm. PS: Danke für das Lob
9. Juni 2011 um 20:39 Uhr
Hallo Christoph,
Ich überlege mir schon seit längerem mir eine SSD anzuschaffen und werde dies wahrscheinlich in den nächsten Wochen tun.
Leider finde ich nur wenig kompakte Infos, welche noch dazu aktuell sind und die Besonderheiten zum optimalen Betrieb von Ubuntu auf SSDs behandeln.
Steht dein Plan noch dazu einen eigenen Artikel zu verfassen?^^
Würde mich sehr freuen!
VG
14. Juni 2011 um 13:55 Uhr
Ähm, ja… der Plan steht noch. Hätte ich nicht soooo viel zu tun. Ich will in dem Bereich keinen “Mist” schreiben und vorher gut recherchieren. Das braucht aber seine Zeit. Ich schaue zu dass ich dazu was bringe.
28. Juni 2011 um 12:25 Uhr
Hi Agrigor, in der aktuellen Linux User 07/2011 ist ein ausführlicher Artikel über SSDs unter Linux. Dem Artikel ist eigentlich nicht mehr viel beizufügen. Hol dir doch mal die aktuelle Ausgabe, so lange sie noch im Handel zu bekommen ist. Grüße, Christoph.
29. Juni 2011 um 19:43 Uhr
Hallo Christoph,
vielmals Danke für den Hinweis. Habe das Heft soeben bestellt, da ich es in den umliegenden Zeitschriftenläden und Tankstellen nicht gefunden habe.
VG Agrigor
16. Juni 2011 um 00:27 Uhr
Cool Danke dir!!!
VG
19. August 2011 um 21:38 Uhr
Hallo und vielen Dank für den Artikel
sehr verständlich geschrieben.
Ich habe eine Frage, ich betreibe einen kleinen debian Server in meinem lokalen Netzwerk welcher mir als Datenspeicher dient. Wenn ich hier die Datenfestplatte schlafen lege, wacht sie nicht wieder auf, wenn über das Netzwerk auf die Daten zugegriffen wird. Versuche ich lokal, also auf dem Server selbst, auf die Daten zuzugreifen, fährt die Platte wieder hoch.
Kann man das auch für Netzwerkzugriffe einstellen?
Danke im voraus
Pingback: Automatisierte Entschlüsselung der ext. Festplatte und Backup | DSIW
Pingback: Dreambox/Linux – Festplatte automatisch in den Standby schicken – hdparm | loggn.de – Tutorials und Erfahrungen
5. Mai 2012 um 11:34 Uhr
Ein Thread im UU-Forum bringt mir deinen Eintrag wieder ins Gedächtnis: Warum hast du eigentlich in der hdparm.conf einen kompletten Kommandozeilenbefehl eingetragen, also hdparm -S 60 /dev/undsoweiter? In meiner hdparm.conf (Stand 12.04) sehen die Beispiele so aus:
#/dev/hda { # mult_sect_io = 16 # write_cache = off # dma = on #}D.h. dein Eintrag lautete dann nach diesem Muster:
/dev/disk/by-uuid/4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe { spindown_time = 60 }Liegt das nur an der neueren Version von hdparm oder hat dein Vorgehen einen speziellen Grund?
Bei mir hat der Eintrag in hdparm.conf nämlich überhaupt nichts gebracht. Ohne viel Fehlersuche habe ich die Sache stattdessen von der rc.local erledigen lassen.
13. Juli 2012 um 14:58 Uhr
Ich denke mal, dass sich hier in der Zwischenzeit was geändert hat, ich bringe den Beitrag mal auf einen aktuellen Stand.
Grüße
Christoph
11. Mai 2012 um 21:42 Uhr
Danke für den Artikel.
In meiner hdparm.conf steht vor den Beispielen: “Any of the blocks that use command line syntax must begin with the keyword ‘command_line’”. Demnach müßte es korrekterweise lauten:
command_line { hdparm -S60 /dev/sdb }Gruß, Jan
6. September 2012 um 23:51 Uhr
Vielen Dank für den Artikel!
Hat mir geholfen!
5. Oktober 2012 um 09:08 Uhr
Hallo,
erst einmal Danke für diesen und viele andere tolle Beiträge. Ich habe in meinem Notebook ebenfalls eine SSD für das System sowie home und eine HDD zum Auslagern größerer Dateisammlungen etc. Auf letztere habe ich jetzt auch alle Bilder und die Musik meines home-Verzeichnisses verschoben und symbolisch verlinkt, in der Hoffnung, dass die Festplatte nur noch anfängt zu lärmen, wenn ich auf diese Bilder oder die Musik zugreife. Tut sie aber nicht. Liegt das am symbolischen Link, also dass das System regelmäßig home ausliest, auf den Link stößt und dann die Platte hochfährt? Oder wie?
Danke schonmal und Grüße
FJ
5. Oktober 2012 um 10:42 Uhr
Update: Symlinks testweise entfernt, Festplatte fährt dennoch hoch. Die Partition ist darüberhinaus nicht gemountet.
5. Oktober 2012 um 10:13 Uhr
Auch von mir noch eine Frage: Das Schlafenlegen klappt zwar gut, aber wie lässt sich verhindern, dass beim Runterfahren die Platten kurz hochtouren, nur um dann gleich ausgeschaltet zu werden?
5. Oktober 2012 um 10:25 Uhr
Dieses “Problem” habe ich auch bemerkt, dachte mir aber, dass das ein kurzer Systemcheck vorm Schlafengehen ist und daher besser so bleibt. Falls nicht, schallte ich das natürlich auch gern ab (sollte evtl. auch das Runterfahren beschleunigen?).
Gruß
8. Oktober 2012 um 00:52 Uhr
Schaut euch mal diesen Thread aus dem Archlinux-Forum an: Spun-down hard disk being spun-up just before poweroff. Das Sys-File /sys/class/scsi_disk/1\:0\:0\:0/manage_start_stop finde ich auch auf einem aktuellen Ubuntu. Man müsste also vor dem Shutdown via “hdparm -C /dev/sdX” prüfen ob die Platte heruntergefahren wurde, und falls ja “echo 0 > /sys/class/scsi_disk/1\:0\:0\:0/manage_start_stop” ausführen. (Festplattenbezeichnungen natürlich noch anpassen).
Grüße
Christoph
10. Oktober 2012 um 09:40 Uhr
Super, vielen Dank. Wenn die Gerätebezeichnungen unter /sys/class/scsi_disk fest sind, müsste es so gehen. Werde ich ausprobieren.
23. Oktober 2012 um 09:48 Uhr
Schade, die Lösung funktioniert nicht. Auch mit gesetzter 0 fährt die Platte noch beim Shutdown hoch. Die Ausgabe zeigt derweil “Deactivating Swap”, ob das zusammenhängt, weiß ich nicht. Swappartition habe ich jedenfalls gar keine.
13. November 2012 um 08:35 Uhr
Hallo!
Danke für den guten Artikel!
Einige Unklarheiten habe ich bloß noch:
Ich betreibe einen Debian-Fileserver mit Software-Raid 6, aber das sollte sich ja nicht weiter unterscheiden von Ubuntu.
Mit hdparm -S kann ich den Timer einwandfrei aktivieren. Interessanterweise ist er auch noch nach dem Neustart aktiv. Eine Idee wo das gespeichert wurde?
blkid gibt mir dann 6 Raid-Festplatten mit der selben UUID aus: (Auszug)
/dev/sde1: UUID=”8316cb9d-ce52-8bbf-0f4d-aba57bd50064″ TYPE=”linux_raid_member”
/dev/sdf1: UUID=”8316cb9d-ce52-8bbf-0f4d-aba57bd50064″ TYPE=”linux_raid_member”
/dev/sdg1: UUID=”8316cb9d-ce52-8bbf-0f4d-aba57bd50064″ TYPE=”linux_raid_member”
Wenn ich diese wie beschrieben in die hdparm conf eintrage:
/dev/disk/by-uuid/8316cb9d-ce52-8bbf-0f4d-aba57bd50064
{
spindown_time = 244
write_cache = off
}
passiert das:
/etc/init.d/hdparm reload
[FAIL] Setting parameters of disc:[....] unknown option /dev/disk/by-uuid/8316cb9d-ce52-8bbf-0f4d-aba57bd50064 … failed!
Nun habe ich geschaut und kann unter /dev/disk/by-uuid/ auch nur 4 Angaben finden, worunter nicht die obige UUID aufgeführt ist.
Ne Idee wodran es liegt?
Grüße, Rupert
1. Dezember 2012 um 06:08 Uhr
Hi coole Anleitung werde ich die tage auf meinem Daten und Druck server ausprobieren.
Habe auch ne kleine ssd und für Daten normale hdd’s
24. Dezember 2012 um 17:01 Uhr
Hallo,
Super Anleitung, Danke !
MAl eine Frage hierzu (geht zwar um ein spezielles System –> Pogoplug) aber man kann das ja ableiten :
Was passiert, wenn ich HDPARM in die RC.LOCAL mit aufnehme….jetzt kommt es aber…wenn die HDD die ich hier angebe (externe) beim Start nicht eingesteckt ist ??
Danke für die Info !
24. Dezember 2012 um 17:47 Uhr
Dann passiert gar nichts.
27. Dezember 2012 um 12:05 Uhr
Gibt es denn eine Möglichkeit das wo einzutrage, dass es nur dann erfolgt, sobald eine USB Platte angesteckt wird….?
Wenn ja wo oder wie mache ich das ?
Danke für die tolle Hilfe !
27. Dezember 2012 um 19:42 Uhr
Hi, das geht über udev. Siehe bspw. im Wiki von Ubuntusers http://wiki.ubuntuusers.de/udev#Beispiele-fuer-eigene-udev-Regeln Grüße, Christoph
27. April 2013 um 14:09 Uhr
Danke für das Tut, es funktionierte bis vor kurzem einwandfrei.
Doch nachdem ich auf 12.10 geupdated hatte ging die Festplatten weder per hdparm.conf noch per hdparm -S 1 /dev/sdb in den Standby, nur per hdparm -y legt sie sich schlafen.
bei hdparm -B /dev/sdb kommt:
/dev/sdb:
APM_level = not supported
woran könnte das liegen ?
5. Mai 2013 um 18:15 Uhr
Bei mir hat jede einzelne Partition einer HD laut blkid eine andere ID.
blkid – locate/print block device attributes !
gdisk -l nennt ganz andere IDs, aber nur eine pro HD.
Man schaltet nicht block devices ab, sondern physisch ganze HDs.
7. Mai 2013 um 05:58 Uhr
Super! Festplatte schlafen legen
funktioniert auch mit meinem Raspberry Pi unter Raspbian
uname -a
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux