Priorytety operacji I/O Ubuntu Karmic Koala

[pioruns]

Witam, posiadam laptopa Asus A6JC, jego podstawowe parametry:
Processor: 2x Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz
Motherboard: Intel Corporation Mobile 945GM/PM/GMS
Memory: 1539MB (1105MB used)
Operating System: Ubuntu 9.10
OpenGL Renderer : GeForce Go 7300/PCI/SSE2
HDD: ATA WDC WD2500BEVE-0
DVD-RAM: HL-DT-ST DVDRAM GMA-4082N

Log z lspci: http://wklej.org/id/209000/?zawin=0

Problem jest taki, że podczas kopiowania danych z dysku komputer się straszliwie zamula. Terminal się otwiera 10s, przełączanie okien to kilka sekund, kursor myszki też potrafi się przyciąć. Np. kopiuję pliki z partycji na partycję, prędkość to 4-10MB/s, w tym czasie prawie nic nie da się zrobić, otwarcie jakiegoś programu to kwestia 2 minut lub więcej.
I teraz mam do was pytanie: czy da się jakoś ustawić w systemie niższy priorytet na operacje kopiowania lub przenoszenia danych? Lub jakiś większy bufor na to? Bo teraz rozpoczęcie operacji dyskowych = zamuła systemu na kilka minut, np. gdy chcę parę filmów przenieść. Da się coś z tym zrobić?
Czekam na wasze propozycje:)

[sinat-ra]

Jak dokonałeś takiego zapchania RAMu ? Masz takie użycie pamięci cały czas czy tylko przy kopiowaniu ?

[OldEnt85]

Prawdopodobnie używasz NTFS, a za tym idzie duże użycie procesora. Przejście na ext3/ext4 i inne linuksowe będzie obejściem problemu...

[Tomahawk]

hdparm -i /dev/sda

Daj wynik polecenia

[pioruns]

/dev/sda:

Model=WDC, FwRev=01.01A01, SerialNo=WD-WXH108072498
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7

* signifies the current active mode

Tak, używam też partycji NTFS, czasami też potrzebuję coś na nie wrzucić lub skopiować. System Ubuntu jest na ext4, jednak na innych partycjach mam Windowsa i NTFSa.
Różnica jest taka, że podczas kopiowania z ext4 na ext4 jest trochę szybciej i mniej zamula. Jednak dalej to nie jest to.
A jak zapycham tak RAM? Żebym to ja wiedział... W tej chwili hardinfo pokazuje: 862MB used, a mam otwarte: Firefox, aMule, Pidgin, hardinfo, Banshee, sesję ssh w terminalu a drugi pusty terminal. Nic więcej. Gnome-system-monitor podaje inny wynik: 680MB used. Nie wiem skąd te programy mają takie rozbieżności?

PS. Czasami, podczas kopiowania z (lub na) NTFS kopiowanie trwa, 5MB/s, a później coraz bardziej zwalnia, nawet to kilkuset kilobajtów na sekundę... Czym to może być spowodowane? Też tak macie? Niejednokrotnie też, gdy podłączam przenośny dysk USB z NTFS, kopiuje mi się na niego 300kB/s, a zużycie procesora wynosi cały czas 100%. Te problemy mogą być powiązane z tym, co opisałem w pierwszym poście.

[brii]

Prawdopodobnie używasz NTFS, a za tym idzie duże użycie procesora. Przejście na ext3/ext4 i inne linuksowe będzie obejściem problemu...

Raczej wątpię - na słabyszm procku pod Ubuntu kopiuję pomiędzy partycjami NTFS z prędkościami rzędu 30MB/s i bez problemów reszta systemu działa. Obstawiam, że nie masz włączego DMA albo masz ustawiony tryb kompatybilny pracy kontrolera dysków.

[dk75]

ql
Skoro masz mulący w I/O system to może coś byś potestował?

Kod: Zaznacz cały

sudo su
echo "anticipatory" > /sys/block/sda/queue/scheduler

( to będzie działać tylko do ponownego bootu - na stałe się ustawia inaczej )

Normalnie scheduler I/O jest ustawiony na "CFQ" - ten scheduler stara się każdemu procesowi który potrzebuje dostępu do dysku przyznać po równo transferu dzięki temu każdy proces z dyskiem pracuje równolegle do innych ( i podobno maksymalizuje się wykorzystanie transferu ).
Ale w pewnym artykule o RedHat4 wyczytałem, że scheduler "Anticipatory" jest bardziej "interaktywny" ( okienka nie przycinają w trakcie - serwerowi to nie przeszkadza bo nie ma okienek ) i w związku z tym bardziej nadaje się dla stacji roboczych i komputerów jednostanowiskowych gdy "CFQ" jest zbawieniem dla rozległych serwerów.
Więc może... przynajmniej niektóre objawy "uśmierzy" gdyż przyczyna rzeczywiście może być inna ( ale UDMA5 jest więc...). W końcu "milijony" użyszkodników "U" nie narzeka i nawet nie wie, że ma "CFQ" ustawione w standardzie.

Ja testuję teraz na tanademie ION/Atom który w testach dostał ocenę "jego bolączką jest słaby transfer dyskowy który kładzie wszystko".

PS: hdparm się używa tylko do dysków/napędów ATA, dla SATA jest sdparm