Autor: Artur Gawryszczak (gawrysz_at_camk.edu.pl._!_!_!_)
Data: Mon 04 Nov 2002 - 17:50:37 MET
Radoslaw Sokol wrote:
> Artur Gawryszczak wrote:
>> Wyjątkowo się nie zgodzę z Tobą, Radku :-P Takie kopiowanie będzie
>> przebiegało fatalnie wyłącznie tak długo, jak długo jest realizowane
>> przez jakieś getchar()/putchar() (a najwyraźniej M$ tak to zrobił), bo
> Oj, zdecydowanie nie zrobił. Operacje dyskowe (przynajmniej w
> rodzinie NT) to w sporej części normalne inpage/outpage przeno-
> szone na sektory dysku.
Pomiarami bawiłem się niegdyś na W98, w NT faktycznie mogło być to
zrobione profesjonalniej. Między wykorzystaniem getchar()/putchar() (a
właściwie fgetc/fputc) a fgets/fputs na buforze wielkości sektora, lub
kilku sektorów nie było różnicy ani w prędkości kopiowania, ani w
głośności rzeźbienia głowicą. Przy buforze rzędu 1MB lub więcej dysk
stanowczo cichł, a prędkość rosła. Może w XP już to poprawili - nie wiem,
nie używam, ale prymitywniejsze windowsy mocno cierpią z powodu domyślnie
krótkiego bufora (lub może jego braku).
> IIRC standard IDE nie przewiduje bezpośredniej możliwości
> skopiowania danych zawartych w cache kontrolera do innych
> sektorów (popraw mnie, jeśli się mylę).
Niestety nie wnikałem w materię aż tak dogłębnie :)
> Każda operacja
> kopiowania dysków między partycjami musi więc polegać na
> odczytaniu fragmentu pliku do RAMu, po czym zapisaniu
> tegoż fragmentu w nowym miejscu dysku.
> Dopóki ma się do czynienia z prostymi systemami plików (vide
> FAT) problem nie jest wielki: system alokuje bufor określonej
> wielkości (dla przykładu w NT zależy on od rozmiaru pamięci
> i najczęściej wynosi około 8 MB). Zawartość pliku jest czytana
> do bufora i zapisywana w nowym miejscu. Na końcu następuje
> aktualizacja tablicy alokacji i katalogu.
8MB bufor dla pojedynczego kopiowania po partycji to już jest
przyzwoicie, bo nawet przy najszybszych dyskach to jest zaledwie ze 6
dłuższych ruchów głowicy na sekundę na zdefragmentowanym pliku. Przy
takim buorze kopiowanie po dysku będzie szło niemal z połową max.
transferu sekwencyjnego.
> Gorzej jest z małymi plikami (parę/paręnaście kilo to przypadek
> już ekstremalny) -- system plików _powinien_ po skopiowaniu
> każdego pliku opróżnić bufory i zapisać w sposób _pewny_
> tablicę alokacji i katalog. Inaczej staje się niebezpieczny.
> Mogę się mylić, ale IIRC rodzina NT zawsze aktualizuje FAT
> i katalog zaraz po zamknięciu pliku, a dane pliku zapisuje
> co najwyżej po paru sekundach.
Hmmm... Dos Navigator najpierw kopiował do bufora, potem go opróżniał.
FAT aktualizował (jeśli wierzyć komunikatom) po zakończeniu kopiowania
grupy plików, co miało ten minus, że pad zasilania mógłby unieważnić
kopiowanie, ale szczególnie niebezpieczne dla struktur logicznych nie
było. Nie bardziej niż robienie tego pojedynczo.
> Jeszcze gorzej jest z systemami transakcyjnymi (w szczegól-
> ności NTFSem), gdzie każde zapisanie bufora pociąga za sobą
> kilka dodatkowych machnięć głowicami w celu zaktualizowania
> logów transakcji. Kopiowanie plików między dwiema partycjami
> NTFS to już masakra, co wiem z doświadczenia. Do tego dochodzi
> nie do końca IMHO przemyślane przeplatanie operacji dyskowych,
> bo procesy dopominające się w czasie takiego kopiowania dos-
> tępu do dysku potrafią być pod NT zawieszona na paręnaście
> dobrych sekund.
Oj straszne rzeczy wypisujesz. Jak to dobrze, ze ja ostatnio mam do
czynienia głównie z Ext2/Ext3, nawet po NFS-ie (100Mbit) nie ma takich
cyrków :-)
--
Pozdrówka,
Artur
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 01:52:17 MET DST