Ubuntu niszczy dyski w notebookach?

[lukk]

ubuntu.pl prezentuje:

W sobotę natknąłem się na błąd "default value in power.sh potentially kills laptop disks" zgłoszony na launchpadzie (tu odnośnik: https://bugs.launchpad.net/ubuntu/+s...ort/+bug/59695).
Na początku go zignorowałem uspokojony odpowiedzią jednego z programistów Ubuntu, ale później sprawdziłem sam i muszę przyznać, że jestem lekko zszokowany.

Problem dotyczy zarządzania energią, a dokładnie zarządzania energią dla dysku twardego. Jeszcze konkretniej ilości cykli obciążenia. W dużym skrócie, ich przyrost może być cholendarnie szybki. Producenci dysków wskazują na wartości 300.000 do 600.000 takich cykli, za wyższe wartości nie dają odpowiedzialności. Mój dysk ma ok 14 miesięcy i jest ich już 1.230.345 i już dawał oznaki słabości.

Sprawdź czy to dotyczy także Ciebie:
-potrzebna będzie aplikacja smartcrl , (są w pakiecie smartmontools -> sudo apt-get install smartmontools).
Uruchamiamy je poleceniem:
sudo smartctl -d ata -a /dev/sda . Odszykujemy tam Load_Cycle_Count i czytamy ostatnią kolumnę. W celu ułatwienia pozwolę je sobie jeszcze wygrepować:
sudo smartctl -d ata -a /dev/sda | grep Load_Cycle_Count

Jeżeli odnotowujesz znaczny przyrost tej wartości (jeden z człowieków sugeruje, że bezpiecznie jest gdy wartość nie przyrasta szybciej niż 90 cykli na dobę, co jest całkiem rozsądną wartością) to polecam z zapoznaniem się z trzema wpisami na tym blogu:
http://ubuntudemon.wordpress.com/
Znajdziecie tam też rozwiązanie, przynajmniej czasowe i skuteczne.

[yacup]

nie za bardzo łapię wynik testu: czy mogę prosić o interpretację (dysk w laptopie, laptop kupiony -nowy- w kwietniu 2006 roku)

root@laptop:/home/jakub# sudo smartctl -d ata -a /dev/sda
smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     TOSHIBA MK1032GSX
Serial Number:    556L4887S
Firmware Version: AS021H
User Capacity:    100,030,242,816 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   6
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sun Oct 28 22:14:54 2007 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
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:                 ( 384) 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:        (  76) minutes.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   097   050    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       1611
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       5531
  5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail  Always       -       1
  7 Seek_Error_Rate         0x000b   100   100   050    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   050    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   088   088   000    Old_age   Always       -       5113
 10 Spin_Retry_Count        0x0033   210   100   030    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1456
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       164
193 Load_Cycle_Count        0x0032   088   088   000    Old_age   Always       -       128547
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       46 (Lifetime Min/Max 5/52)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
220 Disk_Shift              0x0002   100   100   000    Old_age   Always       -       182
222 Loaded_Hours            0x0032   092   092   000    Old_age   Always       -       3398
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
224 Load_Friction           0x0022   100   100   000    Old_age   Always       -       0
226 Load-in_Time            0x0026   100   100   000    Old_age   Always       -       325
240 Head_Flying_Hours       0x0001   100   100   001    Pre-fail  Offline      -       0

SMART Error Log Version: 1
ATA Error Count: 1
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 1 occurred at disk power-on lifetime: 4223 hours (175 days + 23 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 48 c9 fe ea  Error: UNC 8 sectors at LBA = 0x0afec948 = 184469832

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 48 c9 fe ea 00      00:07:06.682  READ DMA
  c8 00 08 50 89 fe ea 00      00:07:06.681  READ DMA
  c8 00 08 48 89 fe ea 00      00:07:06.681  READ DMA
  c8 00 08 38 fb d7 ea 00      00:07:06.670  READ DMA
  c8 00 08 d8 f5 d7 ea 00      00:07:06.659  READ DMA

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

yacup

[Sir_Yaro]

193 Load_Cycle_Count 0x0032 088 088 000 Old_age Always - 128547

wiec general nie duzo. sprawdz w jakim tempie ta wartosc u ciebie wzrasta. jesli wiecej niz 90-100 na dobe to powinienes sie tym zainteresowac

[yacup]

Napisał Sir_Yaro

193 Load_Cycle_Count 0x0032 088 088 000 Old_age Always - 128547

wiec general nie duzo. sprawdz w jakim tempie ta wartosc u ciebie wzrasta. jesli wiecej niz 90-100 na dobe to powinienes sie tym zainteresowac

dzięki, ale w tym teście dosyć dużo jest wartości opisanych jako "old-age" oraz "pre-fail"

MAM SIĘ TYM NIE PRZEJMOWAĆ ???

[lukk]

U Ciebie chyba nie ma jakichś wielkich anomalii.

Jeżeli ktoś rozpoznał u siebie taki przypadek, a nie zna za dobrze angielskiego, lub nie ma czasu się w to wgłębić to rozwiązanie (przynajmniej tymczasowe) jest następujące:
Zaczynamy od sprawdzenia czy jest włączony Laptop_mode w /etc/default/acpi-support. Jeżeli tak to go wyłączamy (powinien mieć wartość false - domyślnie)
Tworzymy skrypt, np w GEdit o następującej treści:

#!/bin/sh
hdparm -B 255 /dev/sda
hdparm -S0 /dev/sda

Nazywamy go np 99-hdd-spin-fix.sh (ważne aby nazwa zaczynała się od 99-), nadajemy atrybut wykonalności:
sudo chmod +x 99-hdd-spin-fix.sh
i umieszczamy go w trzech folderach:
/etc/acpi/suspend.d/
/etc/acpi/resume.d/
/etc/acpi/start.d/
Wystarczy je tylko przeładować.
Jeżeli nadal zauważacie wzrost liczby cykli możecie spróbować zamiast wartości 255 w skrypcie użyć 254 (u mnie działa właśnie tak).

Radzę nie ignorować tego zjawiska, tak jak przed zgłębieniem problemu zrobiono na launchpadzie, oznaczając błąd jak "wishlist" a nie krytyczny, twierdząc że wina leży po stronie producentów sprzętu, a dowiedzione zostało, że odpowiednie wartości modyfikowane są przez system.

[LordD]

Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1161

To jedyne wyrażenie zawierające Cycle Count, w raporcie w ogóle nie występuje słowo "load". A "sudo smartctl -a /dev/sda | grep Load_Cycle_Count" nie wyświetla mi żadnego wyniku.
Więc... nie wiem jak mam odczytać ten raport. Poza tym czy nie lepiej w ogóle wyłączyć ACPI?

[jacekowski]

rozwiazanie na to jest bardzo proste - zwiekszysc standby timeout na jakis znosny np. hdparm -S 200 /dev/sda (kwestia dobrania wartosci w zaleznoscu od wymagan, ekstremalne oszczedzanie baterii kontra zuzycie dysku), wylaczanie laptop mode mija sie z celem bo to powoduje tylko ze system nie budzi dysku jesli nie jest to koniecznie potrzebne, wiec dobrym pomyslem moze byc ustawienie sporego vm.dirty_ratio + vm.dirty_background_ratio + vm.dirty_writeback_centisecs + vm.dirty_expire_centisecs, razem z laptop mode i parominutowym standby timeoutem, wiec przy ogladaniu filmu itp. nie bedzie niepotrzebnie dysku zatrzymywalo a jednoczesnie laptop pozostawiony sam sobie, albo gdy bedzie robione na nim cos co dysku nie uzywa nie bedzie zuzywal niepotrzebnie baterii badz meczyl dysku

[polboy]

Częste parkowanie głowic występuje tylko przy używaniu z baterii, czyż nie?

Mój wynik:

193 Load_Cycle_Count 0x0032 180 180 000 Old_age Always - 62558

Co uważam za wartość dobrą, gdyż używam często komputer (kupiony w styczniu 2007).

[yacup]

No ja mam chyba powody do niepokoju. Kolejne wartości przedstawiają się jak niżej

Wartości:
2007-10-28 godz. 22:16  Load_Cycle_Count 0x0032 088 088 000 Old_age Always - 128547
2007-10-30 godz. 11:16  Load_Cycle_Count 0x0032 088 088 000 Old_age Always - 129848
2007-10-30 godz. 23:01  Load_Cycle_Count 0x0032 087 087 000 Old_age Always - 130792
2007-10-31 godz. 08:39  Load_Cycle_Count 0x0032 087 087 000 Old_age Always - 131002
2007-10-31 godz. 21:42  Load_Cycle_Count 0x0032 087 087 000 Old_age Always - 131394

Przyrosty wartości to około 400 do 500 na dobę. Co mam zrobić, jeżeli można to tak krok po kroku. Tak jak napisał lukk już zrobiłem (chyba nie pomogło)
yacup

[kamel607]

Na liście dyskusyjnej acpi-support pojawiają się niepokojące doniesienia dotyczące zarządzania energią przez Ubuntu. Okazuje się, że domyślnie ustawione w systemie wartości mogą prowadzić do szybkiego uszkodzenia dysku twardego...

Cały problem związany jest ponoć z systemem parkowania głowic, stosowanym współcześnie w bardzo wielu dyskach twardych. Mechanizm dba o to, by w przypadku jałowej pracy HDD głowice zostały umieszczone nad obszarem, którego uszkodzenie nie zniszczy danych w razie wstrząsów.

Użytkownicy twierdzą, że deweloperzy Ubuntu przesadnie przejęli się oszczędzaniem energii. Zawarte w skrypcie /etc/acpi/power.sh polecenie hdparm -B 1 sprawia, że podczas pracy na baterii głowice mogą być parkowane nawet dwa razy na minutę (tzw. load cycle)!

Producenci dysków deklarują, że ich urządzenia wytrzymują średnio 400 tysięcy cykli parkowania. Łatwo wyliczyć, że oznacza to niecałe 139 doby ciągłej pracy przy zasilaniu z akumulatora. Przy założeniu więc, iż każdego dnia korzystasz ze swego laptopa przez trzy godziny dziennie (oczywiście bez podłączania do gniazdka), powinieneś zacząć się martwić po ok. 3 latach.

Rozwiązanie problemu znajdziemy na stronie: https://wiki.ubuntu.com/DanielHahler/Bug59695

Źródło: PC World Komputer, Autor: Łukasz Bigo

[http://hack.pl/aktualnosci/ubuntu_ni...tebookach_797]

[goomior]

Otóż okazuje się, iż to nie twórcy Ubuntu odpowiedzialni są za zbyt wysoki LOAD_CYCLE_COUNT. Ubuntu, lub inny GNU/Linux pozwala jednak w prosty spsosób oszacować przyrost ilości parkowania głowicy. Okazuje się bowiem, iż w innych systemach również napotkano na ten problem. Burza została rozpętana na anglojęzycznej Planecie Ubuntu przez niejakiego Roalda Hopmana, który po wnikliwszej analizie problemu i konsultacjach z osobami kompetentnymi wycofał się ze wszelkich zarzutów. Źródło. Póki co zatem problem jest zamknięty.

W Ubuntu mozna łatwo sprawdzić i monitorować ilość parkowania głowicy dysku twardego poprzez:

sudo smartctl -a /dev/sda | grep Load_Cycle_Count

Jeżeli liczba rośnie dramatycznie w ilości powyżej stu na dzień, należy coś temu zaradzić. Rozwiązanie można znaleźć w sieci. U mnie jak widać problem występuje:

16937 25.10.2007
17072 26.10.2007
17412 28.10.2007
17558 29.10.2007
17607 30.10.2007
17871 01.11.2007

[prawdapunk]

Wydaje mi się że bardziej kompetentne informacje znajdziemy tutaj: http://bytowisko.pl/?p=1002 niż na stronie hacka.
Tak czy siak dzięki tej informacji odkryłem, że chyba mój dysk twardy w laptopoie był użytkowany przed jego zakupieniem , bo 98616 Cycle_Count to chyba dużo jak na Laptopa którego mam od lipca.

[goomior]

Prawdapunk, najlepiej sprawdź wartość parametrów Power_On_Seconds oraz Start_Stop_Count. Jeżeli będą dużo wyższe niż wynikające z Twojego stylu użytkowania laptopa, to albo kupiłeś "półkownika" albo faktycznie ktoś go wcześniej uzywał.

[franek]

GG, przedtem FF na laptopie HP 530
193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 5413

Laptop (dysk Hitachi) tylko pracuje pod Ubuntu, dosyć często na baterii. Jak widać problem go nie dotyczy. Wg mnie jest to raczej błąd dysków i ich liczników niż systemu operacyjnego, choć zarządzanie energią nie działa pod Linuksem tak dobrze jak pod Windows.

[tamaszekk]

Niestety gdy chcę zrobić test wyskakuje mi komunikad [code]Error Counter logging not supported[code]*

Co zrobić?

[Biotrek]

W ciągu 21 minut naliczyłem 12 parkowań, co daje na dobę nieco ponad 800. No i nie ma co ukrywać, że problem występuje.

Wartości:
2007-11-01 godz. 19:25   193 Load_Cycle_Count   0x0032  097  097  000   Old_age   Always  -  72309
2007-11-01 godz. 19:46   193 Load_Cycle_Count   0x0032  097  097  000   Old_age   Always  -  72321

Dysk ATA FUJITSU MHV2060B
Lapek ma około rok.
Jeszcze poobserwuję wyniki, później najwyżej zrobię jak Lukk napisał i podam co wyszło z tego.

================================================== =========================

Napisał franek

GG, przedtem FF na laptopie HP 530
193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 5413

Laptop (dysk Hitachi) tylko pracuje pod Ubuntu, dosyć często na baterii. Jak widać problem go nie dotyczy. Wg mnie jest to raczej błąd dysków i ich liczników niż systemu operacyjnego, choć zarządzanie energią nie działa pod Linuksem tak dobrze jak pod Windows.

Nawet gdyby to nie zmienia faktu, że powinno się zaingerować.

[arturchapi]

Witam
Niestety błąd ten występował na moim lapku - Toshiba Satellite A100-011 z dyskiem Hitachi HTS541616J9SA00. Laptop ma 8 miesięcy i preinstalowaną Viste. Ubuntu 7.10 GG mam od kilku dni. W czasie pracy na baterii Ubuntu zwiększył wartość Load_Cycle_Count o 100 w przeciągu godziny.

Problem udało mi sie rozwiązać w następujący sposób:

1. zainstalowane laptop-mode-tools
praca z podłączonym zasilaczem

2. edycje pliku

/etc/laptop-mode/laptop-mode.conf

należy odnaleźć wpis

CONTROL_HD_POWERMGMT=0

i zmienić wartość na 1 ( CONTROL_HD_POWERMGMT=1 )

Po wykonaniu tych czynności wartość Load_Cycle_Count przestała wzrastać.

Obecnie:
Load_Cycle_Count 0x0012 098 098 000 Old_age Always - 26415

Zastanawia mnie wpis w /etc/default/acpi-support

# Switch to laptop-mode on battery power - off by default as it causes odd
# hangs on some machines
ENABLE_LAPTOP_MODE=false

pomimo tego zmiany odniosły skutek.

[Cedric]

Ale to dotyczy tylko laptopów, prawda?

[Biotrek]

Jeśli masz blaszaka na baterie to dotyczy też ciebie

PS.
Zrobiłem wg. porady lukk'a i parkowania ustały Całe szczęście bo jeszcze 24h nie minęły a licznik dobijał do 900 parkowań
Użyłem wartości 254.

PS2.
Co najciekawsze Windows nie jest wcale lepszy, jak na Ubuntu przestało parkować czego jestem pewien w 100% tak przełączyłem się na XPka z zamiarem przetestowania czy tu także problem występuje. Przed uruchomieniem zapisałem stan parkowań, komp pochodził sobie parędziesiąt minut na nim i z powrotem przełączyłem na Ubuntu. Po odpaleniu terminala i wpisaniu polecenia ku mojemu zaskoczeniu liczba parkowań zwiększyła się o 75 co jest jednoznaczne z faktem, że Microsoft winien coś z tym fantem zrobić bo ma u siebie tego samego "buga"

[admo]

Czy to jest kwestia nowego ubuntu (nowych linuksów) czy tak się działo już od dawna? Mam rocznego laptopa z wartością Load_Cycle_Count = 3667. Chyba naprawdę niewiele, pomimo tego, że często pracuje na baterii.
Aha, wydaje mi się, że problem leży po stronie samych dysków twardych. Może warto zainteresować się aktualizacją firmware?
Pozdrawiam.