OVH Community, your new community space.

Dysk IO


victor
16-03-2012, 23:32
Cytat Napisał Joshua
Co do innodb - ważne by mysql miał włączoną opcję innodb_file_per_table - wtedy zamiast wielkiego i podatnego na uszkodzenie pliczyska każda tabela ma własny plik indeksów.
log transakcji jest wspólny. Zapewne jeśli crash nastąpi podczas flushowania loga do plików ibd to oba będą uszkodzone.

Joshua
16-03-2012, 22:05
Cytat Napisał victor
Dyskusja, moja wiedza na ten temat (gdzieś się mylę?)

brak włączonego barrier może spowodować uszkodzenia systemu plików (przy crash-ach). Uszkodzenia mogą być całkowite i system plików nie będzie dawał się zamontować i fsck nie pomoże (???)

Writeback zamiast ordered może powodować że w plikach zapisywanych w trakcie crasha mogą pojawić się błędne dane (ew. także dane innych użytkowników, ale trudne do wykorzystania). Jakie ma to implikacje dla systemu bazodanowego jak mysql?? Myisam ma repair tables, ale wg. mnie nie we wszystkich typach uszkodzeń to pomoże. Innodb ma swój system naprawczy oparty na logu tranzakcji. A co jeśli to log zostanie właśnie uszkodzony? - to pytanie jest wg. mnie tutaj najciekawsze
Zgadza się, użycie nobarrier i writeback zwiększa ryzyko awarii przy padzie zasilania - ale tak jak już pisałem, spadek wydajności przy przejściu na ext4+barrier jest nieakceptowalny. Awarie zasilania zdarzają się rzadko, a straty z powodu obniżonej wydajności dają w kość 24h/dobę. Biorąc pod uwagę, że mimo wszystko z reguły pad zasilania nie oznacza jednak zniszczenia partycji i plików - warto podjąć ryzyko. A gdy liczy się pewność - częste backupy + replikacja na bieżąco na inną maszynę.
Co do innodb - ważne by mysql miał włączoną opcję innodb_file_per_table - wtedy zamiast wielkiego i podatnego na uszkodzenie pliczyska każda tabela ma własny plik indeksów.

Spacedust
16-03-2012, 20:42
Cytat Napisał victor
Dyskusja, moja wiedza na ten temat (gdzieś się mylę?)

Najnowsza wersja (vanila) kernel montuje:
ext3 z writeback i nobarrier
ext4 z ordered i barrier
(a może to nie kernel definiuje defautlowe parametry??)

Co oznacza że przy przerzuceniu się z ext3 na ext4 bez zmiany parametrów montowania wydajność się zmiejszy (o ile ext4 sam w sobie nie sprawuje się wystarczająco lepiej)

brak włączonego barrier może spowodować uszkodzenia systemu plików (przy crash-ach). Uszkodzenia mogą być całkowite i system plików nie będzie dawał się zamontować i fsck nie pomoże (???)

Writeback zamiast ordered może powodować że w plikach zapisywanych w trakcie crasha mogą pojawić się błędne dane (ew. także dane innych użytkowników, ale trudne do wykorzystania). Jakie ma to implikacje dla systemu bazodanowego jak mysql?? Myisam ma repair tables, ale wg. mnie nie we wszystkich typach uszkodzeń to pomoże. Innodb ma swój system naprawczy oparty na logu tranzakcji. A co jeśli to log zostanie właśnie uszkodzony? - to pytanie jest wg. mnie tutaj najciekawsze
Słuszne uwagi, generalnie nie ryzykować na hostingu i na ważnych rzeczach, nawet jeśli się ma Hardware RAID z BBU. Jeśli ma być maksymalna wydajność, a dane są niezbyt ważne to można ryzykować.

victor
16-03-2012, 20:16
Dyskusja, moja wiedza na ten temat (gdzieś się mylę?)

Najnowsza wersja (vanila) kernel montuje:
ext3 z writeback i nobarrier
ext4 z ordered i barrier
(a może to nie kernel definiuje defautlowe parametry??)

Co oznacza że przy przerzuceniu się z ext3 na ext4 bez zmiany parametrów montowania wydajność się zmiejszy (o ile ext4 sam w sobie nie sprawuje się wystarczająco lepiej)

brak włączonego barrier może spowodować uszkodzenia systemu plików (przy crash-ach). Uszkodzenia mogą być całkowite i system plików nie będzie dawał się zamontować i fsck nie pomoże (???)

Writeback zamiast ordered może powodować że w plikach zapisywanych w trakcie crasha mogą pojawić się błędne dane (ew. także dane innych użytkowników, ale trudne do wykorzystania). Jakie ma to implikacje dla systemu bazodanowego jak mysql?? Myisam ma repair tables, ale wg. mnie nie we wszystkich typach uszkodzeń to pomoże. Innodb ma swój system naprawczy oparty na logu tranzakcji. A co jeśli to log zostanie właśnie uszkodzony? - to pytanie jest wg. mnie tutaj najciekawsze

Joshua
16-03-2012, 13:59
Cytat Napisał borec
Jakieś testy sam robiłeś, czy opierasz swoje twierdzenia na jednym benchmarku znalezionym w necie? Pewnie, jak chcesz hardkorowo, to wyłącz journal, też będzie szybciej, co nie znaczy, że lepiej, albo że z journalem nie da się używać filesystemu pod bazę.
Trafiłem na tę stronę nie dlatego że nie lubię ext4, tylko dlatego że miałem problemy z bazami mysql postawionymi na ext4. Na nowym, wypasionym serwerze baza wypełniała się z dumpa około godzinę - zamiast ok. 10 minut, jak to było na starym rachitycznym sprzęcie. Eliminowałem poszczególne poszlaki - wpływ vserverów, cgroup itd. - aż w końcu okazało się że winne jest ext4. Po zmianie na ext4 czas wypełnienia bazy danymi skrócił się do bodajże 3 minut.

Spacedust
16-03-2012, 13:56
Da się używać bez problemu, ale IO zwykłych dysków przy pewnej ilości operacji na bazie po prostu i tak nie wyrabia, dlatego zalecam SAS z hardware RAID lub SSD dla baz danych.

borec
16-03-2012, 13:06
Cytat Napisał Joshua
O, proszę:

http://themech.net/2011/10/strugglin...s-under-linux/

Partition type Time (in seconds)
ext2 49
ext3 40
ext4 160
ext4 * 201
ext4 (nobarrier) 42
jfs 54
xfs 124
btrfs 166

Nie wykluczam że problem jest do ominięcia inaczej niż przez barrier=0, ale nie znalazłem nigdzie innego rozwiązania.
Jakieś testy sam robiłeś, czy opierasz swoje twierdzenia na jednym benchmarku znalezionym w necie? Pewnie, jak chcesz hardkorowo, to wyłącz journal, też będzie szybciej, co nie znaczy, że lepiej, albo że z journalem nie da się używać filesystemu pod bazę.

Joshua
15-03-2012, 15:32
Cytat Napisał borec
Skądże takie mądrości nabyłeś? Ext4 z barrier nieużywalny pod bazę?
O, proszę:

http://themech.net/2011/10/strugglin...s-under-linux/

Partition type Time (in seconds)
ext2 49
ext3 40
ext4 160
ext4 * 201
ext4 (nobarrier) 42
jfs 54
xfs 124
btrfs 166

Nie wykluczam że problem jest do ominięcia inaczej niż przez barrier=0, ale nie znalazłem nigdzie innego rozwiązania.

borec
15-03-2012, 12:49
Cytat Napisał Joshua
Tylko że z barierami czasami spadek wydajności jest katastrofalny - w przypadku baz danych system w ogóle nie nadaje się do użytku Przy writeback trudno się dziwić że miałeś kłopoty - to jest fajne conajwyżej na dane tymczasowe, zbyt ryzykowne dla ważnych danych.
Skądże takie mądrości nabyłeś? Ext4 z barrier nieużywalny pod bazę? Dyrdymały jakich mało, dobrze skonfigurowana baza prawie nie jeździ po dysku. A płacz będzie wielki przy hard resecie z barrier=0. Warte jest to zachodu tylko przy intensywnym write i gdy nie przeszkadza rozsypanie filesystemu przy awarii.

Poczytajcie lepiej o stride,stripe-width,commit.

Spacedust
15-03-2012, 10:16
Cytat Napisał Joshua
Tylko że z barierami czasami spadek wydajności jest katastrofalny - w przypadku baz danych system w ogóle nie nadaje się do użytku Przy writeback trudno się dziwić że miałeś kłopoty - to jest fajne conajwyżej na dane tymczasowe, zbyt ryzykowne dla ważnych danych.
Nie stwierdzam tego problemu, ale do baz danych mam OCZ-Vertex3 w innej serwerowni

Joshua
15-03-2012, 08:38
Cytat Napisał Spacedust
Dlatego ja powróciłem jednak do barier, bo w tej konfiguracji, która mam teraz nawet najgorsze awarie zasilania obyły się bez żadnego sprawdzania filesystemu, a kiedyś przy reiserfs + writeback niemal straciłem wszystkie dane.
Tylko że z barierami czasami spadek wydajności jest katastrofalny - w przypadku baz danych system w ogóle nie nadaje się do użytku Przy writeback trudno się dziwić że miałeś kłopoty - to jest fajne conajwyżej na dane tymczasowe, zbyt ryzykowne dla ważnych danych.

Spacedust
14-03-2012, 20:13
Cytat Napisał victor
osobiście po przerzuceniu się z ext3 nobarrier writeback an ext4 barrier ordered nei zauważyłem pogorszenia wydajności, ale napewno gdzieś tam jest.
Wszystko pięknie i ładnie, wyłączacie zabezpieczenia w systemie plików przed padami zasilania, ale pamiętajcie że takowe w ovh się zdarzają 1-2 razy na rok minimum.
Dlatego ja powróciłem jednak do barier, bo w tej konfiguracji, która mam teraz nawet najgorsze awarie zasilania obyły się bez żadnego sprawdzania filesystemu, a kiedyś przy reiserfs + writeback niemal straciłem wszystkie dane.

victor
14-03-2012, 20:06
osobiście po przerzuceniu się z ext3 nobarrier writeback an ext4 barrier ordered nei zauważyłem pogorszenia wydajności, ale napewno gdzieś tam jest.
Wszystko pięknie i ładnie, wyłączacie zabezpieczenia w systemie plików przed padami zasilania, ale pamiętajcie że takowe w ovh się zdarzają 1-2 razy na rok minimum.

Spacedust
14-03-2012, 19:13
Cytat Napisał desavil
?

Obecnie mam ustawione tak:
Kod:
/dev/sda2       /home   ext4    defaults,noatime,nodiratime,barrier=0       0       2
To z writeback miałbyś już całkowicie bez "bulletproof".

desavil
14-03-2012, 19:04
?

Obecnie mam ustawione tak:
Kod:
/dev/sda2       /home   ext4    defaults,noatime,nodiratime,barrier=0       0       2

Spacedust
14-03-2012, 19:00
A writeback ?

Joshua
14-03-2012, 18:52
Cytat Napisał desavil
Czyli ustawić tak:
Kod:
/dev/sda2       /home   ext4    defaults,barrier=0       0       2
I powinna się zwiększyć wydajność?
Nie ma gwarancji - to bardzo pomaga przy dużej ilości operacji, np. gdy na partycji ext4 stoi baza danych to może dojść do różnic gdzie bez barrier=0 wrzucenie bazy z dumpa trwa 5 godzin a z barrier=0 kilka minut Generalnie wydajność powinna się zwiększyć, może się zwiększyć drastycznie ale to już kwestia indywidualna.

Aaa i jedna sprawa: wrzucenie barrier=0 to teoretycznie pogorszenie bezpieczeństwa danych - filesystem jest mniej "bulletproof"... Ale coś za coś Ja nie wyobrażam sobie działania bez barrier=0...

desavil
14-03-2012, 18:43
Czyli ustawić tak:
Kod:
/dev/sda2       /home   ext4    defaults,barrier=0       0       2
I powinna się zwiększyć wydajność?

Czy tak:
Kod:
/dev/sda2       /home   ext4    defaults,noatime,nodiratime,barrier=0       0       2

Joshua
14-03-2012, 17:42
Cytat Napisał desavil
ext4 był domyślnie ustawiony wraz z zainstalowanym systemem (Debian 6.0 64bit).
Jeżeli możesz powiedzieć, jak dodać to: barrier=0?
Tak samo jak te noatime itd. - w 4. kolumnie w fstab
BTW, nie musisz pisać np "defaults,noatime,nodiratime" - to "defaults" jest potrzebne tylko gdy nie ustawiasz żadnych dodatkowych opcji

Spacedust
14-03-2012, 17:41
Cytat Napisał Joshua
Przede wszystkim w ext4 dodaj barrier=0, bo bez tego parametru ext4 jest mułem jakich mało... A nawet jak się doda barrier=0 to jest nadal nieznacznie wolniejszy od ext3.
Dopisałem u siebie też

desavil
14-03-2012, 17:30
ext4 był domyślnie ustawiony wraz z zainstalowanym systemem (Debian 6.0 64bit).
Jeżeli możesz powiedzieć, jak dodać to: barrier=0?

Joshua
14-03-2012, 15:06
Cytat Napisał Spacedust
Dodaj noatime,nodiratime i powinno być sporo lepiej
Przede wszystkim w ext4 dodaj barrier=0, bo bez tego parametru ext4 jest mułem jakich mało... A nawet jak się doda barrier=0 to jest nadal nieznacznie wolniejszy od ext3.

maxxx
14-03-2012, 12:17
http://www.webhostingtalk.com/showth...2k#post7586383
http://www.webhostingtalk.com/showth...mb#post7219108

Funkywizard ma stadko proxów pod yt dla arabusów (http://www.alexa.com/siteinfo/vtunne...om+ktunnel.com) i z tego co mówił z 18 najtańszych maszyn ze stajni 100tb.com wyciąga 9gbps płacąc coś poniżej 3k$. Więc być może wie jak optymalizować wydajność hdd. :-)

Spacedust
13-03-2012, 17:21
Cytat Napisał desavil
Teraz wzrosło DISK WRITE
No i dobrze

desavil
13-03-2012, 17:15
Teraz wzrosło DISK WRITE

desavil
13-03-2012, 15:39
Dzięki!
Zobaczę jak będzie się spisywać

Spacedust
13-03-2012, 15:35
Cytat Napisał desavil
Tylko dla /dev/sda2 i relatime w /dev/sda2 usunąć tak?

Tak to ma być?:
Kod:
/dev/sda1       /       ext4    errors=remount-ro,relatime      0       1
/dev/sda2       /home   ext4    defaults,noatime,nodiratime       0       2
/dev/sda3       none    swap    defaults        0       0
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0
I reboot serwera
mount -o remount /dev/sda2 powinno wystarczyć, bez rebootu

desavil
13-03-2012, 15:34
Tylko dla /dev/sda2 i relatime w /dev/sda2 usunąć tak?

Tak to ma być?:
Kod:
/dev/sda1       /       ext4    errors=remount-ro,relatime      0       1
/dev/sda2       /home   ext4    defaults,noatime,nodiratime       0       2
/dev/sda3       none    swap    defaults        0       0
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0
I reboot serwera

Spacedust
13-03-2012, 15:32
Cytat Napisał desavil
Dzięki pokombinuję najpierw z tę drugą opcją.

Kod:
/dev/sda1       /       ext4    errors=remount-ro,relatime      0       1
/dev/sda2       /home   ext4    defaults,relatime       0       2
/dev/sda3       none    swap    defaults        0       0
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0
Dodaj noatime,nodiratime i powinno być sporo lepiej

desavil
13-03-2012, 15:24
Dzięki pokombinuję najpierw z tę drugą opcją.

Kod:
/dev/sda1       /       ext4    errors=remount-ro,relatime      0       1
/dev/sda2       /home   ext4    defaults,relatime       0       2
/dev/sda3       none    swap    defaults        0       0
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0

Spacedust
13-03-2012, 15:13
Cytat Napisał desavil
Chyba nie:
Kod:
System plików         rozm. użyte dost. %uż. zamont. na
/dev/sda2             1,8T  385G  1,4T  23% /home
Serwer ma 24GB ramu.

Więc myślę teraz co tutaj mogę zrobić, aby jakoś to działało.
To Varnish powinien spełnić swoją funkcję, ale będziesz musiał parę dni nad konfiguracją posiedzieć

Ewentualnie spróbuj włączyć writeback na dysku i jeśli masz ext3 to przejdź na ext4 i ustaw noatime w /etc/fstab.

desavil
13-03-2012, 14:52
Chyba nie:
Kod:
System plików         rozm. użyte dost. %uż. zamont. na
/dev/sda2             1,8T  385G  1,4T  23% /home
Serwer ma 24GB ramu.

Więc myślę teraz co tutaj mogę zrobić, aby jakoś to działało.

Spacedust
13-03-2012, 14:51
Cytat Napisał desavil
Nie mam tam zainstalowanej bazy danych, tylko usługi streamingowe, które nadają, odczytują pliki MP3, a następnie wysyłają (nadają) na serwer streamingu.
Proponujesz jakieś ciekawe rozwiązanie na to?

Oprócz zmiany serwera oczywiście hehe.
Można też użyć Varnish jak najbardziej, ale wiele plików MP3 się w RAM'ie nie zmieści, wtedy zostają Tobie dyski SAS lub SSD, można spróbować też RAID10 na dyskach SATA.

desavil
13-03-2012, 14:33
Nie mam tam zainstalowanej bazy danych, tylko usługi streamingowe, które nadają, odczytują pliki MP3, a następnie wysyłają (nadają) na serwer streamingu.
Proponujesz jakieś ciekawe rozwiązanie na to?

Oprócz zmiany serwera oczywiście hehe.

Spacedust
13-03-2012, 14:30
Zainteresuj się memcache, varnish i poprawą ustawień MySQL'a, wtedy dysk będzie miał znacznie lepszą wydajność.

desavil
13-03-2012, 13:55
Czyli przeciążony tak?

A jak bym przeniósł usługi na serwer z dyskiem: WDC WD2002FAEX-007BA0, może lepiej by działało?

Dodatkowo na tym serwerze gdzie dysk obciążony mam takie coś:
Kod:
 3834 root           0 B/s   25.71 K/s  0.00 % 10.29 % [jbd2/sda2-8]
 2071 root           0 B/s    0.99 K/s  0.00 %  7.77 % [jbd2/sda1-8]
Co to za procesy, bo one czasem mają największe obciążenie i/O?

Smart:
Kod:
=== START OF INFORMATION SECTION ===
Device Model:     WDC WD2002FAEX-007BA0
Serial Number:    WD-WMAY02967254
Firmware Version: 05.01D05
User Capacity:    2,000,398,934,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Tue Mar 13 14:54:57 2012 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:  (0x84) Offline data collection activity
                                        was suspended by an interrupting command from host.
                                        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:                 (28500) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        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:        ( 255) minutes.
Conveyance self-test routine
recommended polling time:        (   5) minutes.
SCT capabilities:              (0x3037) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

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     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   253   253   021    Pre-fail  Always       -       8558
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       71
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   097   097   000    Old_age   Always       -       2877
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       69
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       68
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       2
194 Temperature_Celsius     0x0022   114   111   000    Old_age   Always       -       38
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      2163         -
# 2  Short offline       Completed without error       00%      2151         -
# 3  Short offline       Completed without error       00%      2151         -
# 4  Short offline       Completed without error       00%      2135         -
# 5  Short offline       Completed without error       00%      2135         -
# 6  Short offline       Completed without error       00%      2114         -
# 7  Short offline       Completed without error       00%      2114         -
# 8  Short offline       Completed without error       00%      1987         -
# 9  Short offline       Completed without error       00%      1987         -
#10  Short offline       Completed without error       00%      1010         -
#11  Short offline       Completed without error       00%       998         -
#12  Short offline       Completed without error       00%       998         -
#13  Short offline       Completed without error       00%        18         -
#14  Short offline       Completed without error       00%         6         -
#15  Short offline       Completed without error       00%         6         -

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.

Spacedust
13-03-2012, 13:50
Tak, ale nie wymagaj super wydajności od pojedynczego dysku zwłaszcza zwykłego SATA2/3.

desavil
13-03-2012, 13:27
Ostatnio na moim serwerze strasznie zaczęło mulić coś usługi, które prowadzę.
Procesor/pamięć/łącze w normie ataków niema żadnych.

Tak więc rozmyślam o co tutaj może chodzić... Postanowiłem zobaczyć iotop
Dał mi taki wynik:
Kod:
Total DISK READ: 7.91 M/s | Total DISK WRITE: 0.75 M/s
Mój dysk to: Segate ST32000641AS
Czy nie jest czasem dysk przeciążony?

Dodatkowo daję jeszcze smart:
Kod:
=== START OF INFORMATION SECTION ===
Device Model:     ST32000641AS
Serial Number:    9WM483RN
Firmware Version: CC13
User Capacity:    2,000,398,934,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 4
Local Time is:    Tue Mar 13 14:27:06 2012 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
See vendor-specific Attribute list for marginal Attributes.

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:                 ( 609) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        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:        (   1) minutes.
Extended self-test routine
recommended polling time:        ( 255) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   111   099   006    Pre-fail  Always       -       33874685
  3 Spin_Up_Time            0x0003   100   100   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       7
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   084   060   030    Pre-fail  Always       -       283904630
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       6786
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       7
183 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
184 Unknown_Attribute       0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   053   030   045    Old_age   Always   In_the_past 47 (83 64 65 35)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       2
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       6
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       7
194 Temperature_Celsius     0x0022   047   070   000    Old_age   Always       -       47 (0 31 0 0)
195 Hardware_ECC_Recovered  0x001a   050   029   000    Old_age   Always       -       33874685
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       58007828306583
241 Unknown_Attribute       0x0000   100   253   000    Old_age   Offline      -       291378779
242 Unknown_Attribute       0x0000   100   253   000    Old_age   Offline      -       4204751185

SMART Error Log Version: 1
No Errors Logged

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.