# Jak sprawdzić co korzysta z dysku?

## canis_lupus

Problem jest następujący:

Usypiam sobie dysk poleceniem 

hdprm -y /dev/sda

po czym po kilku sekundach on włącza się z powrotem

próbowałem wyłączyć cron'a i swap to nie to. 

Jak sprawdzić jaki program (proces?) budzi mi dysk?

----------

## Paczesiowa

moze pobaw sie fuser

pozatym to moga byc np logi czy cos...

----------

## no4b

lsof?

----------

## canis_lupus

fuser nie poda mi procesu który ostatnio uzywał dysku tylko procesy które maja otwarty jakis plik.

----------

## Paczesiowa

moze atop?

http://www.atconsultancy.nl/atop/whyatop.html#advantages

pierwsze 2 punkty wygladaja przydatnie

----------

## mar_rud

lm-profiler z pakietu laptop-mode-tools.

Podaje jaki program dostawał się do dysku, np:

```
lapek marcom # lm-profiler

Profiling run started.

Accesses at 16/600 in run: akregator bash run-crons sa1 sadc sh

Accesses at 29/600 in run: akregator

Accesses at 31/600 in run: kio_http kio_http_cache_

Accesses at 32/600 in run: kio_http kio_http_cache_

Accesses at 78/600 in run: akregator

Accesses at 82/600 in run: firefox-bin

Accesses at 83/600 in run: kwin

Accesses at 98/600 in run: kwin

Accesses at 101/600 in run: kwin

Accesses at 103/600 in run: firefox-bin kdesktop kwin

Accesses at 106/600 in run: firefox firefox-bin kdesktop mozilla-launche xdpyinfo

Accesses at 107/600 in run: firefox-bin

Accesses at 108/600 in run: firefox-bin

Accesses at 109/600 in run: bonobo-activati firefox-bin

Accesses at 110/600 in run: firefox-bin kwin

Accesses at 111/600 in run: konsole

Accesses at 112/600 in run: konsole

Accesses at 114/600 in run: firefox-bin

Accesses at 116/600 in run: firefox-bin

Accesses at 171/600 in run: kded

Accesses at 222/600 in run: knode
```

Poza tym polecam w temacie zasilania dysku:

Zarządzanie zasilaniem dla dysku twardego

----------

## Radioaktywny

Witam

Czy przypadkiem winne nie jest księgowanie?

----------

## mar_rud

Potestowałem sobie i można obejść się bez lm-profile, który i tak nie jest idealny.

Najskuteczniejszą metodą pomiaru, co się z dyskiem dzieje, jest:

```
echo 1 > /proc/sys/vm/block_dump
```

W efekcie wszelkie zapisy/odczyty są raportowane do sysloga. Z tego wynika, że należy zmodyfikować na ten czas sysloga i wyłączyć plik /var/log/messages i zostawić tylko wyświetlanie na /dev/tty12 (czy np. /dev/console dla xconsole).

Od tej pory w syslogu będą wpisy zawierające nazwę procesu, pid, typ operacji oraz partycję i nazwa samego pliku. Typ operacji, to m.in: READ, WRITE, dirted inode.

U mnie (reiserfs) przebiega to tak, że jakiś proces coś modyfikuje/odczytuje (wpis dirted inode .... lub READ/WRITE), po czym najczęściej proces pdflush dodatkowo wykonuje zapis. Przy zabawie opcją commit przy montowaniu partycji reiserf, zapis zmian przez pdflush może być po pewnym czasie, jednak nie tak jak myślałem (po kilku sekundach, zamiast tyle co nastawiłem). Budzenie dysku następuje właśnie przy READ/WRITE.

Przykładowo źródła dostępu do plików, jakie znalazłem u siebie:

- pdflush co 5 sekund(księgowanie) = zapomniałem o dodaniu opcji noatime w fstab

- zapisy do /var/log/* (np. cupsd, acpid, Xorg, kdm, ...)

- programy użytkowe (skype, akregator, kadu, knode, ...) do partycji /home

W praktyce ze względu na liczne programy wyłączenie dysku na więcej niż kilkadziesiąt sekund jest u mnie niemożliwe bez użycia laptop-mode-tools, chociaż i tak mam problemy z konfiguracją (zapisy chyba powinny być odroczone o 10min, a nie są).

----------

## canis_lupus

Wielkie dzięki za sugestie, jak tylko przejdzie update world'a to zacznę z tym walczyć i napiszę o wynikach...

SKLEJONE:

Kurcze, dysk mi sie budzi, a syslog nie zgłasza w tym momencie żadnych operacji na dysku :/

Co gorsza lm-profiler tez nie.

od raku: no postcount++

----------

## mar_rud

Jeśli włączyłeś:

```
echo 1 > /proc/sys/vm/block_dump
```

to przy byle odczycie/zapisie powinno być bardzo dużo wpisów w syslogu(przypominam o wyłączeniu zapisu do pliku, bo dodatnie sprzężenie zwrotne powstanie). Czy przy zapisach/odczytach widzisz te wpisy (tak jak opisywałem: dirted READ/WRITE block ...)? Po włączeniu tej opcji trudno, aby jakakolwiek aktywność nie została zarejestrowana. Z moich doświadczeń, lm_profiler nie wyświetla wszystkiego, np procesu pdflush związanego z księgowaniem.

Jeśli jednak dysk się budzi pomimo braku aktywności, to może jakiś demon analizy S.M.A.R.T. dysku działa w tle? Ja mam tylko hddtemp jednak to nie przeszkadza, jedynie raportuje 0 stopni, gdy dysk jest uśpiony.

Jak długo wytrzymuje dysk w trybie uśpienia?

----------

## canis_lupus

Wpisy w syslogu są, ale nie w momencie budzenia się dysku. Dysk uśpiony wytrzymuje od 0 do 7 sekund.

Ok! Jednak są co chwilkę wpisy od:

pdflush

kjurnald

Rozumiem że to coś z księgowaniem...

Wczesniej tez miałem księgowanie a dysk usypiac mogłem.

mój system plików:

```
tune2fs -l /dev/sda1

tune2fs 1.39 (29-May-2006)

Filesystem volume name:   <none>

Last mounted on:          <not available>

Filesystem UUID:          9b3439db-0e0f-488c-9add-47419c7525fa

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      has_journal dir_index needs_recovery large_file

Default mount options:    journal_data

Filesystem state:         clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              8960896

Block count:              8960245

Reserved block count:     448012

Free blocks:              6991862

Free inodes:              8528991

First block:              0

Block size:               4096

Fragment size:            4096

Blocks per group:         32768

Fragments per group:      32768

Inodes per group:         32704

Inode blocks per group:   1022

Last mount time:          Fri Jul 13 15:23:11 2007

Last write time:          Fri Jul 13 15:23:11 2007

Mount count:              13

Maximum mount count:      20

Last checked:             Mon Jul  2 19:00:16 2007

Check interval:           15552000 (6 months)

Next check after:         Sat Dec 29 18:00:16 2007

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               128

Journal inode:            8

Default directory hash:   tea

Directory Hash Seed:      4ebfacc7-c874-4eb2-93b2-7c1ae3642218

Journal backup:           inode blocks

```

----------

## mar_rud

U mnie na reiserfs mam w fstab opcję noatime, aby wyłączyć zapis do dysku co ok 5s związany z atrybutem czasu dostępu do pliku. Jednak rzeczy związane z księgowaniem bez opcji noatime były widoczne w syslogu (proces pdflush) i poza tym, przy monitorowaniu dysku np gkrellm widać było na wykresie ladny grzebień z małymi pikami co 5s.

Proponuję zamieścić jeszcze zawartość /etc/mtab. 

UPDATE w trakcie pisania:

Właśnie sprawdziłem po przesiadce na libata i mam podobny objaw co canis_lupus. Brak wpisów w syslog, a dysk się budzi. Wczoraj dopiero (przy okazji nowego jądra) zmieniłem na nowy sterownik SATA/PATA (wcześniej używałem zwykłego ATA), więc chyba jest to z tym związane. Sprawdziłem hddtemp i chyba on jest winowajcą w moim przypadku. Wcześniej przy uśpionym dysku nie zwracał nic (nie wiem dokładnie, gkrellm2 wyświetlał 0 stopni). Teraz wywołując hddtemp z konsoli dysk się budzi, a w syslogu pusto. Dysk nie śpi więcej niż kilkanaście sekund. Po wyłączeniu (/etc/init.d/hddtemp stop), dysk "przespał" się ok półtorej minuty, zanim nie dopadł go acpid z jakimś nieistotnym wpisem w /var/log/acpid.

A tutaj wynik hddtemp'a z różnymi opcjami, dopiero przy drugim wywołaniu dysk się budzi

```
lapek linux # sync && hdparm -y /dev/sda

  /dev/sda:

  issuing standby command

lapek linux # hddtemp PATA:/dev/sda

  /dev/sda: ST98823A                                �: drive is sleeping

lapek linux # hddtemp SATA:/dev/sda

  /dev/sda: ST98823A: 42°C

lapek linux # hddtemp /dev/sda

  /dev/sda: ST98823A: 42°C

lapek linux # hddtemp PATA:/dev/sda

  /dev/sda: ST98823A                                �: 42°C
```

Zatem należałoby sprawdzić, czy nie jest włączona jakaś usługa związana z nadzorem dysku poprzez SMART (np. hddtemp, czy smartd).

Jeśli nie jest to przyczyną w Twoim przypadku, to skończyły mi się pomysły.Last edited by mar_rud on Fri Jul 13, 2007 12:47 pm; edited 1 time in total

----------

## canis_lupus

Mtab:

```

/dev/sda1 / ext3 rw,noatime 0 0

proc /proc proc rw 0 0

sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0

udev /dev tmpfs rw,nosuid 0 0

devpts /dev/pts devpts rw,nosuid,noexec 0 0

/dev/sda3 /mnt/win_c vfat rw,umask=0,iocharset=iso8859-2 0 0

/dev/sda5 /mnt/win_d vfat rw,umask=0,iocharset=iso8859-2 0 0

/dev/sda6 /mnt/win_e vfat rw,umask=0,iocharset=iso8859-2 0 0

none /dev/shm tmpfs rw,noexec,nosuid,nodev 0 0

usbfs /proc/bus/usb usbfs rw,noexec,nosuid,devmode=0664,devgid=85 0 0

binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,noexec,nosuid,nodev 0 0

```

Nie mam ani hddtemp ani smartd.

Mnie dysk budzi pdflush wiem że to on bo go widzę. Tylko co zrobić aby go nie budził?

----------

## Poe

więc tak. sprawdziłem z ciekawosci jak to u mnie jest z usypianiem. mam dysk segate, ata z libata w kernelu. wszystko na laptopie HP. włączylem usypanie dysku, uspił się i śpi tak długo, dopóki go nie obudzę myszką i jakimis operacjami. klikaniami itp, takze to niekoniecznie wina libata (kernel 2.6.20-ck1), fs to reiserfs.

----------

## canis_lupus

Ja mam dysk na SATA, wczesniej (2 tygodnie temu) miałem starego PATA i było to samo.

----------

## mirekm

A może ktoś spotkał się z czymś takim?

Accesses at 219/600 in run: md2_raid1

Accesses at 220/600 in run: md2_raid1

Accesses at 223/600 in run: md2_raid1

Accesses at 224/600 in run: md2_raid1

Accesses at 227/600 in run: md2_raid1

Accesses at 228/600 in run: md2_raid1

Accesses at 229/600 in run: md2_raid1

Accesses at 232/600 in run: md2_raid1

Accesses at 233/600 in run: md2_raid1

Accesses at 236/600 in run: md2_raid1

Accesses at 237/600 in run: md2_raid1

Accesses at 241/600 in run: md2_raid1

Accesses at 245/600 in run: md2_raid1

Accesses at 246/600 in run: md2_raid1

Accesses at 250/600 in run: md2_raid1

Accesses at 254/600 in run: md2_raid1

Accesses at 258/600 in run: md2_raid1

Accesses at 259/600 in run: md2_raid1

Accesses at 263/600 in run: md2_raid1

Accesses at 267/600 in run: md2_raid1

Accesses at 272/600 in run: md2_raid1

Accesses at 276/600 in run: md2_raid1

Accesses at 277/600 in run: md2_raid1

Accesses at 281/600 in run: md2_raid1

Accesses at 285/600 in run: md2_raid1

Accesses at 286/600 in run: md2_raid1

Accesses at 290/600 in run: md2_raid1

Accesses at 294/600 in run: md2_raid1

Accesses at 295/600 in run: md2_raid1

Accesses at 297/600 in run: md2_raid1

Accesses at 299/600 in run: md2_raid1

Accesses at 302/600 in run: md2_raid1

Accesses at 303/600 in run: md2_raid1

Accesses at 304/600 in run: md2_raid1

Accesses at 306/600 in run: md2_raid1

Bo chciałbym uspić dyski, ale nie wiem czym ugryźć to cholerstwo.

----------

## canis_lupus

Po bardzo długich bojach, po zmianie dysku, kilkakrotnie jajaka, po paredziesiątkrotnym przekompilowaniu jaja z różnymi opcjami i bez, stwierdzam, że się poddaję. Nie mam juz na to siły. Będę po prostu co rok zmienial dysk (bo chodzi 24/7 i już).

----------

## Ravak

Chyba raz na 10 lat. Bardziej się opłaca dyskowi pracować 24/7 niż włączać i wyłączać np. raz dziennie.

To co niszczy dysk to stany nieustalone przy włączaniu i wyłączaniu zasilania.

----------

## sza_ry

Częste usypianie i budzenie dysku wykończy go szybciej niż stała stabilna praca. Trzeba tylko zadbać aby się nie przegrzewał.

Dawno nie kupowałem dysku, ale ostatnim razem jak sprawdzałem statystykę od jakiegoś producenta (bezawaryjny średni czas pracy i starty dysku) wychodziło że dysk jest przewidziany na 10h pracy przy jednym starcie.

Prawda statystyczna jest jak wiadomo gorsza niż półprawda  :Wink:  Daje to jednak jakiś obraz.

Dzięki za informacje o procesach korzystających z dysku, przy okazji spróbuję powalczyć o ciszę  :Smile: 

edit: Ravak szybszy.

----------

## canis_lupus

Mój poprzedni dysk miał przepracowane ponad 5000h a włączany był ok 80 razy.

----------

