Forum Debian Users Gang

hornet · 2011-05-01 00:18:00

Witam,

Posiadam laptop Toshiba S500-13L. Podczas przenoszenia danych z partycji na partycję, transfer zaczyna się od 80 MB/s, następnie spada do ok. 16 MB/s. Czego to może być wina?

Dodam, że mam tak na Windowsie i Debianie.

Pozdrawiam.

thalcave · 2011-05-01 01:06:15

Hmmm... a jak długo te 80MB się utrzymuje... Może tyle jest ustawiane bo tak powinno iść a z jakiegoś względu kopiowanie idzie zdecydowanie wolniej.

Co wykazuje hdparm?

Ostatnio edytowany przez thalcave (2011-05-01 01:43:39)

Huk · 2011-05-01 09:16:05

Dyski w lapkach są zwykle sporo wolniejsze od tych ze stacjonarek... no ale 16 MB/s to trochę chyba przesada. Podaj co wypluł hdparm+co pluje dmesg podczas kopiowania+podaj dokładny model dysku.

torrentow · 2011-05-01 09:20:19

można też sprawdzić iostat z paczki sysstat ;)

tomii · 2011-05-01 10:34:02

zależy jakie dane przenosisz, jakieś duże pliki czy masę drobnicy?
Ps i na jakich partycjach operujesz.

Ostatnio edytowany przez tomii (2011-05-01 10:34:42)

SpeedVin · 2011-05-01 11:23:28

[quote=tomii]zależy jakie dane przenosisz, jakieś duże pliki czy masę drobnicy?
Ps i na jakich partycjach operujesz.[/quote]
Koledze tutaj zapewne chodzi o system plików :)
Przyłączam się do pytania.

hornet · 2011-05-01 14:50:55

Te 80 MB/s utrzymuje się przez jakieś 10 sekund, następnie spada do poziomu 16 MB/s. Nie kopiuje drobnicy, tylko seriale po 350 MB. Tego było koło 70 GB. Leciało to z ext4 na ext3.

Kod:

# hdparm /dev/sda

/dev/sda:
 multcount     = 16 (on)
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 60801/255/63, sectors = 976773168, start = 0

Jaki minimalnie transfer powinienem uzyskać na SATA II? Chodzi o realny.

Pozdrawiam.

tomii · 2011-05-01 15:06:58

Wydaje mi się że powinieneś mieć z 2 razy tyle.
Czy któraś z partycji nie była na samym końcu dysku?
Czy dane nie są pofragmentowane?

hornet · 2011-05-01 15:11:22

Partycje są w centrum, najbliżej początku dysku jest Windows. Fsck pokazuje nieciągłość systemu plików na poziomie 0.2%. To chyba jest ta fragmentacja? Czyli niewielka.

tomii · 2011-05-01 15:21:02

Sprawdź pliki pliki programem filefrag, oraz zrób test na świeżo skopiowanych plikach(na partycje źródłową wrzucić pare gb świeżo skopiowanych plików i wtedy sprawdź), ponadto sprawdź co mówi smart może dysk zaczyna mieć problemy.

hornet · 2011-05-01 16:15:04

Pod Windows uruchomiłem HDTune i zapuściłem test:
[url=http://img28.imageshack.us/i/skr1j.jpg/][img]http://img28.imageshack.us/img28/8559/skr1j.jpg[/img][/url]

Jak to oceniacie? Smart jak najbardziej ok.

Filefrag zwraca sporą ilość extensów, więc wydaje mi się, że to może być tego wina. Defragmentować chyba się nie opłaca ext4? Tar, ext2fs i rozpakowanie?

ArnVaker · 2011-05-01 16:38:54

[quote=hornet]Defragmentować chyba się nie opłaca ext4?[/quote]
Przy fragmentacji na poziomie 0.2%? Pewnie że nie… Zresztą znasz kogoś kto faktycznie defragmentował ext4? Ja tylko czytałem/słyszałem że podobno się da — po nałożeniu jakichś tajemniczych dodatkowych łat. Nie mam pojęcia ile w tym prawdy. ;)

hornet · 2011-05-01 17:10:17

Właśnie o tym mówię... też nie znam. ;) Stąd najrozsądniejszym wyjściem jest tar :P

paolus · 2011-05-01 19:05:45

Ja bym stawiał na niewyrabiający dysk. Do zapełnienia bufora transfer jest duży (80) później dysk fizycznie zapisuje dane na talerze i transfer spada. Druga sprawa to kopiowanie na tym samym dysku tj odczyt i zapis na tym samym urządzeniu zawsze będzie wolniejszy. Więcej ramu trochę pomoże tzn dłużej będzie wysoki transfer, ale i tak po zapełnieniu pamięci spadnie.

Nicram · 2011-05-01 19:32:46

[quote=paolus]... kopiowanie na tym samym dysku tj odczyt i zapis na tym samym urządzeniu zawsze będzie wolniejszy...[/quote]
święte słowa dobrodzieju, święte słowa.
Trzeba wziąć pod uwagę, że dyski nie "biegają" po talerzach tak jak to było kiedyś - efektem jest większa żywotność ale za to mniejszy transfer przy użyciu tego samego urządzenia.

hornet · 2011-05-01 20:28:57

Czyli duża prędkość osiągnę tylko na malutkich plikach do paru MB. Pod Windows da się coś zdziałać z tym? RAM'u mam pod dostatkiem, 4GB mi się marnują.

Huk · 2011-05-02 22:58:11

Pod Windos kiedyś (daawno temu, za czasów Win98Se) korzystałem z takiego programu, na którym dało się ustawić dowolną wielkość cache, ale dla CD-Rom'u (VirtualCd się to chyba zwało), wszystko szło do RAM'u rzecz jasna.

Ale podejrzewam że w łatwy sposób czegoś takiego dla dysku zrobić się nie da - bo i jak? Cache działa na zasadzie kilku algorytmów "read ahead" które starają się "zgadnąć" których danych za chwilę user może potrzebować (a to zgadywania działa całkiem dobrze trzeba zaznaczyć), a pewnie takich algorytmów standardowo w kernelu nie ma, a i bezpośredni i niskopoziomowy dostęp do cache dysku raczej nie jest możliwy (tutaj spekuluję, ale zapewne każdy producent ma swoje komendy i API którym dzielić by się nie chciał).

Jak się mylę, niech mnie ktoś poprawi...

Pozdro.

winnetou · 2011-05-02 23:31:27

wrzuć jeszcze wynik dla

Kod:

hdparm -T -t /dev/sda

i spróbuj przemonotować partycje z większym commitem:

Kod:

mount -o remount,commit=60 /punkt/montowania

Time (s)	Query
0.00009	SET CHARSET latin2
0.00004	SET NAMES latin2
0.00059	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.137.218.176' WHERE u.id=1
0.00097	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.137.218.176', 1732551472)
0.00033	SELECT * FROM punbb_online WHERE logged<1732551172
0.00096	DELETE FROM punbb_online WHERE ident='18.191.178.16'
0.00075	DELETE FROM punbb_online WHERE ident='185.191.171.15'
0.00021	SELECT topic_id FROM punbb_posts WHERE id=172138
0.00114	SELECT id FROM punbb_posts WHERE topic_id=18885 ORDER BY posted
0.00043	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=18885 AND t.moved_to IS NULL
0.00033	SELECT search_for, replace_with FROM punbb_censoring
0.00099	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=18885 ORDER BY p.id LIMIT 0,25
0.00077	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=18885
Total query time: 0.0076 s

Forum Debian Users Gang

Ogłoszenie

#1 2011-05-01 00:18:00

hornet - Maruda

transfer danych na dysku

#2 2011-05-01 01:06:15

thalcave - prawie jak admin

Re: transfer danych na dysku

#3 2011-05-01 09:16:05

Huk - Smoleńsk BULWA!

Re: transfer danych na dysku

#4 2011-05-01 09:20:19

torrentow - Członek Sejmowej Komisji Śledczej

Re: transfer danych na dysku

#5 2011-05-01 10:34:02

tomii - Członek DUG

Re: transfer danych na dysku

#6 2011-05-01 11:23:28

SpeedVin - Fan Jogurtu

Re: transfer danych na dysku

#7 2011-05-01 14:50:55

hornet - Maruda

Re: transfer danych na dysku

Kod:

#8 2011-05-01 15:06:58

tomii - Członek DUG

Re: transfer danych na dysku

#9 2011-05-01 15:11:22

hornet - Maruda

Re: transfer danych na dysku

#10 2011-05-01 15:21:02

tomii - Członek DUG

Re: transfer danych na dysku

#11 2011-05-01 16:15:04

hornet - Maruda

Re: transfer danych na dysku

#12 2011-05-01 16:38:54

ArnVaker - Kapelusznik

Re: transfer danych na dysku

#13 2011-05-01 17:10:17

hornet - Maruda

Re: transfer danych na dysku

#14 2011-05-01 19:05:45

paolus - Użytkownik

Re: transfer danych na dysku

#15 2011-05-01 19:32:46

Nicram - Użytkownik

Re: transfer danych na dysku

#16 2011-05-01 20:28:57

hornet - Maruda

Re: transfer danych na dysku

#17 2011-05-02 22:58:11

Huk - Smoleńsk BULWA!

Re: transfer danych na dysku

#18 2011-05-02 23:31:27

winnetou - złodziej wirków ]:->

Re: transfer danych na dysku

Kod:

Kod:

Stopka forum

Informacje debugowania