Share via

Windows 7: kopiowanie wielowątkowe i Shrink Volume

  • Article

W dniu dzisiejszym (18.03.2003) w siedzibie Microsoft odbylo sie spotkanie wszystko o Windows Server 2008 R2 i Windows 7. Mialam przyjemnosc prowadzic prezentacje “Co nowego w Windows Client - Windows 7 i Windows Vista” .

Prezentacja dostepna bedzie na stronach https://microsoft.pl/technet.

Pod koniec prezentacji wirtualna maszyna pewnej firmy niestety z (na razie) nieznanych mi przyczyn calkowicie sie zamrozila. Niemozliwe bylo uzyskanie z jej strony jakiejkolwiek reakcji, mimo iz bootowala sie prawidlowo i pulpit Windows 7 byl widoczny… W efekcie to, co moglam pokazac ze swojego systemu Windows 7 – pokazalam, jesli chodzi o reszte dzialan, to obiecalam Sluchaczom, ze demo, które chcialam pokazac jest calkowicie wykonywalne w domu i zamieszcze na blogu opis krok-po-kroku.

Demo 1 – Robocopy – Celem jest zaprezentowanie wielowatkowego kopiowania plików w Windows 7

Do dema potrzebna jest maszyna z Windows 7, moze byc wirtualna. Do maszyny tej nalezy dodac nowy dysk o stalym niewielkim rozmiarze (celem jest uzyskanie srodowiska, w którym interakcja z “czynnikami zewnetrznymi” bedzie niewielka). Na maszynie fizycznej mozna sie bez tego obejsc.

1. Na nowym dysku (niech bedzie T:\) nalezy zalozyc dwa foldery “Src” oraz “Dst”.

2. Otworzyc konsole cmd.exe, przejsc do folderu “Src” i wprowadzic nastepujace polecenie: for /l %i in (1,1,100000) do echo Created> T:\Src\file%i.txt – polecenie to utworzy 100000 plików.

3. Zakladanie, a pózniej kopiowanie, 100000 plików niestety troche potrwa, ale w pózniejszych krokach czas ten wykorzystany zostanie na obserwacje.

4. W konsoli cmd.exe wpisac polecenie Robocopy T:\Src T:\Dst - Zostanie rozpoczete kopiowanie plików oparte na dwóch watkach (samo kopiowanie jest jednowatkowe, drugi watek wynika z architektury robocopy), czyli po prostu standardowe proste kopiowanie.

5. Uruchomic Windows PowerShell V2 ISE (%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell_ise.exe).

6. W dolnej czesci okna (prompt) wprowadzic polecenie: (get-process robocopy).Threads.Count.ToString() – polecenie to zlicza watki dla procesu “robocopy”. W efekcie powinno sie otrzymac wartosc 2. Liczbe watków dla procesów mozna odnalezc równiez w Task Manager.

7. Po zakonczeniu kopiowania, program “robocopy” wyswietla podsumowanie kopiowania m.in. czas kopiowania. Nalezy zanotowac calkowity czas kopiowania (Total) dla kopiowania jednowatkowego.

7. W konsoli cmd.exe wpisac polecenie Robocopy T:\Src T:\Dst1 /MT:128, gdzie 128 to liczba watków w procesie “robocopy”. Robocopy z parametrem /MT domyslnie wykorzystuje 8 watków+ 1 + 1, czyli 8 watków kopiowania, jeden watek zarzadzajacy wielowatkowoscia (parametrem MT), jeden watek wynikajacy z architektury robocopy. Minimalnie, jako XXX mozna podac 1 watek, maksymalnie 128.

8. Uruchomic Windows PowerShell V2 ISE (%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell_ise.exe).

9. W dolnej czesci okna (prompt) wprowadzic polecenie: (get-process robocopy).Threads.Count.ToString() – w efekcie powinno sie otrzymac wartosc XXX + 2, w tym przypadku 130.

10. Po zakonczeniu kopiowania nalezy zanotowac calkowity czas kopiowania (Total) dla kopiowania wielowatkowego.

Wnioski: Jezeli nic nie zaklócilo przebiegu kopiowania, kopiowanie wielowatkowe powinno przebiegac szybciej. Znane wszystkim kopiowanie (GUI) w Windows Explorer jest kopiowaniem jednowatkowym. Kopiowanie wielowatkowe nie zostalo jeszcze zaimplementowane w systemie Windows 7 Beta w Windows Explorer i chyba raczej nie zapowiada sie, zeby znalazlo sie w wersji finalnej.

Demo 2 – Shrink Volume – zmiany w NTFS

Wbudowana funkcja Shrink Volume w systemie Windows Vista ma pewne ograniczenia. Glównym ograniczeniem jest brak mozliwosci zmniejszenia rozmiaru wolumenu dysku (shrink) nawet, jezeli wolumen zawiera jeszcze troche wolnego miejsca. W efekcie przy próbie zmniejszenia rozmiaru w Disk Management wyswietlana jest wartosc 0 [MB] w polu “Size of available shrink space in MB”. Powodem niemozliwosci skurczenia dysku sa zazwyczaj nieprzenoszalne pliki systemowe znajdujace sie na koncu wolumenu (czy faktycznie tak jest mozna sprawdzic jakims graficznym defragmenterem dysków np. darmowym Auslogics) . Sytuacja taka moze wystapic np. gdy uzytkownik zmniejszyl wolumen o polowe (maksymalne mozliwe zmniejszenie wolumenu w systemie Windows Vista). Dlaczego o polowe?

Aby odpowiedziec na to pytanie nalezy nieco bardziej zaglebic sie w strukture systemu plików NTFS. W implementacji NTFS w Windows Vista mirror MFT (Master File Table, czyli kopia MFT zawierajaca pierwsze 16 rekordów MFT - najwazniejszych) przechowywany jest na srodku wolumenu. Kopia MFT potrzebna jest m.in. do odtworzenia glównego MFT. Uproszczony schemat logiczny wolumenu NTFS wyglada nastepujaco:

image

Rysunek 1. Uproszczony schemat logiczny dla partycji NTFS.

Obszar MFT Zone jest zarezerwowany przez Ntfs.sys i wyliczany podczas montowania wolumenu w oparciu o calosciowy rozmiar.

Z racji tego, ze kopia MFT to nieprzenoszalne pliki systemowe, to Shrink Volume w Vista nie radzi sobie z przeniesieniem tych plików w inne miejsce. Istnieje wiele komercyjnych narzedzi, które potrafia to zrobic. Jesli znacie jakies darmowe narzedzie, które zrobi to dobrze – prosze o umieszczenie informacji w komentarzach. W Windows 7 troche sie pozmienialo. MFT jest przenoszalne i robi to bez problemu wbudowana funkcja Shrink Volume.

Poniewaz Diskpart w niewprawnych rekach jest dosc niebezpiecznym narzedziem nie podaje tu pelnego przepisu krok po kroku (o numerowanie dysków i partycji pytalam na sesji :)) i podpowiem tylko, ze po wybraniu dysku i partycji, o ilosc mozliwych do odzyskania bajtów mozna zapytac poleceniem shrink querymax. Mozna takze skorzystac z GUI Diskmgmt.msc.

Autor: Paula Januszkiewicz

Comments

  • Anonymous
    January 01, 2003
    mgrzeg: Asynchroniczne to jedna bajka a wielowątkowe - inna. I/O od zawsze w Windows było asynchroniczne pod spodem (na poziomie pakietów IRP), ale dla użytkownika dopiero od Visty. I zauważam różnicę na korzyść. Sam piszesz o NCQ - wtedy głowicologia tak nie boli. Poza tym, SSD trafia pod strzechy - też głowicologia odpada. Może się nie znam, ale wolę mieć wybór jedno-, czy wielowątkowe niż mieć do dyspozycji jeden wątek i koniec jak jest teraz.

  • Anonymous
    January 01, 2003
    Stąd, że w przypadku bardzo drobnych plików to nie dyski są problemem, a sterowniki filesystemu są dostosowane do wielowątkowego kopiowania (na tym polega jego siła, a nie na tym, że robocopy ma nowy parametr). Oczywiście wszystko zależy od środowiska uruchomieniowego, dlatego dyskusja jest czysto filozoficzna, wydaje mi się jednak, że jest to cenna możliwość. Co do WE to w Windows 7, to na pewno nie.

  • Anonymous
    January 01, 2003
    @portwajn - Proszę uprzejmie. To chyba pierwsze spotkanie, na które nie zarejestrowała się żadna kobieta! :) @r.kucharski - w drugim zdaniu chodzi zdecydowanie o Windows Explorer, dziękuję za zwrócenie uwagi - już poprawiam!

  • Anonymous
    January 01, 2003
    Gdzieś w planach mam zorganizowanie całodziennego spotkania WiTu - ale to jeszcze chwilkę, zapraszam wtedy - zawsze to dzień cały, a nie parę godzin wieczorem :) Są plany utworzenia WiTów regionalnych, jak tylko coś będę wiedziała, z pewnością napiszę na blogu! Ja również dziękuję!

  • Anonymous
    March 18, 2009
    Dziękuję za wpis, pozdrawiam posesyjnie PS. "Witam Państwa... Państwa... Panów...??" ;-)

  • Anonymous
    March 19, 2009
    Coś mi tu nie gra, albo ja opacznie rozumiem Napisane jest "Do dema potrzebna jest maszyna z Windows 7, może być wirtualna" i "Kopiowanie wielowątkowe nie zostało jeszcze zaimplementowane w systemie Windows 7 Beta i chyba raczej nie zapowiada się, żeby znalazło się w wersji finalnej." To na jakim systemie jest to możliwe? może chodziło o 2008R2?

  • Anonymous
    March 19, 2009
    Szkoda, że temat zrzucają na konsole :( Dziękuję za ciekawy post, szczególnie że WIT jest bardzo warszawski i tak odległe od mojej mieściny ;)

  • Anonymous
    March 19, 2009
    Oj fajna sesja była :) czekamy na następne :) przy okazji będę musiał się przypomnieć, że zostałem zaproszony na kawę ;) PS. właśnie zdałem sobie sprawę, że w nazwie grupy przemyciłaś nazwę swojej Alma Mater ;)

  • Anonymous
    March 24, 2009
    Skad wniosek o szybszym kopiowaniu wielowatkowym w stosunku do calkowicie synchronicznego? Obawiam sie, ze w bardzo ograniczonych przypadkach taki wniosek jest sluszny, a ilosc watkow, 'srodowisko uruchomieniowe' - dyski, sterowniki, etc. maja kluczowe znaczenie dla wynikow eksperymentu. I wcale wiecej watkow nie oznacza poprawy wydajnosci, a czesto jednak znaczace obnizenie. Dlatego tez nie sadze, zeby asynchroniczne IO zostalo zaimplementowana w eksploratorze, ktory powinien jednak dzialac rownie sprawnie na komputerach domowych, co i w sieciach z sanami. m.g.

  • Anonymous
    March 24, 2009
    Asynchroniczne I/O bylo w sumie juz od dawna. Mozna bylo wykonywac w osobnym watku operacje I/O, a takze zlecac podsystemowi asynchroniczna obsluge I/O, wywolujac CreateFile z FILE_FLAG_OVERLAPPED (czy w wersji .NET-> FileStream z FileOptions.Asynchronous). Od pojawienia sie NCQ w SATAnach sprawa przestala dotyczyc wylacznie dyskow SCSI i zeszla pod strzechy. I faktycznie - przy wielu malych plikach rozrzuconych po dysku, w odpowiednim srodowisku sprawa na pewno ma sie dobrze. Jednak bez odpowiedniego srodowiska i przy kopiowaniu duzych plikow, wielowatkowosc tylko pogarsza sprawe w stosunku do calkowicie synchronicznego kopiowania. Dochodzi bowiem narzut na przelaczanie kontekstu, nie wspominajac juz o tworzeniu / niszczeniu watkow, czy tez głowicologii dyskowej. Przyznaje, ze nie przygladalem sie jeszcze blizej W7 i chetnie pobawie sie w wersji finalnej wspomniana wielowatkowoscia.

  • Anonymous
    March 24, 2009
    A przy okazji - ciekawe jaka bedzie roznica przy uruchomieniu RichCopy http://technet.microsoft.com/en-gb/magazine/2009.04.utilityspotlight.aspx na win xp i win 7 :) m.g.