Mounten erzwingen

Andres USB-Festplatte mit 2 Partitionen (FAT32 + NTFS) ließ sich nicht normal mounten. Ich hatte zwar Zugriff auf die FAT32 Partition. Erhielt allerdings eine Unable to mount the volume ‘VNTFS’ Fehlermeldung.

Zugang zu der NTFS Partition erhielt ich erst, nachdem ich das mounten manuell erzwungen hatte:
vdb@Dejiko:~$ sudo mount -t ntfs-3g /dev/disk/by-label/VNTFS /mnt/ -o force

Aushängen funktionierte, wie gewohnt:
vdb@Dejiko:~$ sudo umount /dev/disk/by-label/VNTFS

Temperatur der Festplatte nach HDD Bugfix

Eine Nebenwirkung des Fix für den Festplattenbug von Ubuntu ist, dass die Temperatur der Festplatte ansteigen kann. Eine Problematik, welche der Aufmerksamkeit bedarf.

Zuerst einmal muss geklärt werden, wie warm die eigene Festplatte eigentlich werden darf. In meinem Fall (Hitachi Travelstar 80GN: IC25N040ATMR04) sind es maximal 55°C.

Als hilfreiches Tool zum feststellen der Festplattentemperatur dient z. B. hddtemp, welches schnell mittels sudo apt-get install hddtemp nachinstalliert werden kann. Damit ist es möglich die Temperatur der Festplatte direkt aus dem S.M.A.R.T. der Festplatte auszulesen. Dies geschieht durch die Eingabe des Befehls sudo hddtemp /dev/sda und sieht in meinem Fall so aus:

vdb@Dejiko:~$ sudo hddtemp /dev/sda
/dev/sda: IC25N040ATMR04-0: 35°C

Eine regelmäßige Überprüfung der Temperatur ergab, dass sich diese im normalen Betrieb (Open Office, Internet + MP3s) auf 40°C einpendelt.

Eine stärkere Belastung der Festplatte durch zusätzliche Schreib- und Leseoperationen (Downloads, Uploads, Kopieren von Dateien + Abspielen eines HD Films) führte zwar zu einer Erhöhung der Temperatur, blieb dann aber konstant bei 47°C.

Demnach befinde ich mich trotz Bugfix im sicheren Temperaturbereich der Festplatte und muss mir keine Sorgen machen. Andernfalls hätte ich es mit einer anderen Powermanagementeinstellung der Festplatte probiert (z. B. 220).

Kill-Harddisk-Bug

Es gibt in Ubuntu diesen ziemlich ekligen Bug, welcher die Festplatte zwar nicht direkt schädigt aber ihren Verschleiß doch unverhältnismäßig erhöht.
Danke Goldi, dass du mich darauf hingewiesen hast!
Zur Überprüfung sollte das Paket smartmontools installiert werden. Dann ist es möglich die gesamte Anzahl der Parkpositionen der Festplatte (RAW_VALUE) mit dem Befehl sudo smartctl -a /dev/sda | grep Load_Cycle_Count zu überprüfen. Leider bin ich von diesem Bug auch betroffen. In meinem Fall läuft die Festplatte mit folgendem Werten (sudo hdparm -I /dev/sda | grep Advanced):

Netzbetrieb

$ sudo hdparm -I /dev/sda|grep Advanced
Advanced power management level: 128
* Advanced Power Management feature set

Batteriebetrieb

$ sudo hdparm -I /dev/sda|grep Advanced
Advanced power management level: 1
* Advanced Power Management feature set

So komme ich im Netzbetrieb bereits auf ~80 Parkpositionen pro Stunde. Was viel zu hoch ist! Denn bei 80 Parkpositionen pro Stunde und einer angenommenen Lebensdauer der Festplatte von 600.000 Parkpositionen und einem täglichen Betrieb 10 Stunden würde die Platte (wenn sie neu wäre) nur 600.000/80/10 = 750 Tage halten und wäre somit nach spätestens nach 3 Jahren am Ende.
Ich hätte die Platte also schon weggeworfen. Denn mein Laptop, auf dem bis vor kurzem vorwiegend Windows XP lief, ist inzwischen 4 Jahre alt und hat erst einen RAW_VALUE von ~103.000.

Nun zur Problemlösung: Nach der Installation der laptop-mode-tools musste in der Datei /etc/default/acpi-support erst einmal der Zeile ENABLE_LAPTOP_MODE=false in ENABLE_LAPTOP_MODE=true geändert werden um den Laptop Mode zu aktivieren.

In der Datei /etc/laptop-mode/laptop-mode.conf finden sich die Zeilen

CONTROL_HD_POWERMGMT=1

und

BATT_HD_POWERMGMT=1
LM_AC_HD_POWERMGMT=254
NOLM_AC_HD_POWERMGMT=254

von denen nur BATT_HD_POWERMGMT=1 auf BATT_HD_POWERMGMT=128 geändert werden musste.

Seitdem ergibt sich beim Netzbetrieb ein konstanter RAW_VALUE und im Batteriebetrieb habe ich einen (immer noch schlechten) Kompromiss zwischen Stoßsicherheit und Anzahl der Parkpositionen. Aber die meiste Zeit arbeite ich ja mit bestehender Stromversorgung.

Übrigens ist es ein Unding, dass man über dieses Problem, welches schon seit 7.10 (Gutsy Gibbon) bekannt ist, nicht besser informiert wird und es seitdem auch keinen ordentlichen Fix dazu gegeben hat. Denn es darf einfach nicht sein, dass ein Betriebssystem dazu beiträgt, dass die Hardware eines Rechners beschädigt wird bzw. schneller verschleißt.