Twoje PC  
Zarejestruj się na Twoje PC
TwojePC.pl | PC | Komputery, nowe technologie, recenzje, testy
B O A R D
   » Board
 » Zadaj pytanie
 » Archiwum
 » Szukaj
 » Stylizacja

 
M E N U
  0
 » Nowości
0
 » Archiwum
0
 » Recenzje / Testy
0
 » Board
0
 » Rejestracja
0
0
 
Szukaj @ TwojePC
 

w Newsach i na Boardzie
 
OBECNI NA TPC
 
 » Shark20 02:05
 » MARC 01:57
 » RoBakk 01:51
 » Rybeck 01:27
 » Martens 01:06
 » rainy 00:57
 » spidi 00:42
 » Paweł27 00:36
 » m&m 00:35
 » rzymo 00:35
 » b0b3r 00:22
 » dugi 00:21
 » NWN 00:20
 » Logan 00:16
 » mnih 00:10
 » cVas 00:08
 » Wedrowiec 00:08
 » Visar 00:06
 » Raist 00:04
 » muerte 00:04

 Dzisiaj przeczytano
 41123 postów,
 wczoraj 25974

 Szybkie ładowanie
 jest:
włączone.

 
ccc
TwojePC.pl © 2001 - 2024
A R C H I W A L N A   W I A D O M O Ś Ć
    

jaki szybszy sytem plikow dla pendriv'a ? , McGen 9/01/07 10:12
witam, jaki szybszy FAT czy FAT32 dla w/w ?

..:::McGen GG: 82095:::..

  1. bez roznicy? , Kriomag 9/01/07 10:15
    a z resztą sam sprawdz, co za problem?

  2. a ja zrobiłem NTFS , J@rek 9/01/07 10:25
    mam dodatkowo kompresję plików.

    Aspire5, Honda NC700SD, Mustang M4, Orkan
    3, Talon 4

    1. .'. , ::LinX:: 9/01/07 10:32
      z ciekawości ile dała taka kompresja ??

      MacBook Air 13,3

      1. zalezy co tam trzymasz , Kriomag 9/01/07 10:37
        jak dokmenty worda to da bardzo duzo, jak mp3 i filmy nie da nic :) (podobnie jak zwykla kompresja do zip/rar itp)

        1. .'. , ::LinX:: 9/01/07 10:40
          Bo tak się kiedyś zastanawiałem, czy tego nie włączyć na partycji z XP'kiem.. na ile to by to coś dało i jak wpłynęło na szybkość działania samego systemu...

          MacBook Air 13,3

          1. zrobiłem to , J@rek 9/01/07 10:52
            bo za pena mam starą kartę SD 128MB... trzymam tam FF, mirandę, thunderbirda i kilka innych pierdół.

            na pewno nie zmieszczę tego bez kompresji...
            obrazek... jak to wygląda.
            ftp://stefe.myftp.org/pen.png

            do tego zaszyfrowałem to wszystko truecrypt.

            a często używanych plików raczej nie warto kompresować... przynajmniej jeżeli chcesz szybko i masz niezbyt wydajny sprzęt.

            Aspire5, Honda NC700SD, Mustang M4, Orkan
            3, Talon 4

          2. systemu nie kompresuj bo zwolni dużo , Kriomag 9/01/07 11:21
            miejsca ofc zajmie mniej ale bedzie wolniej, ja kompresowalem partycję z instalkami :) (ostatnio przestalem bo zmienilem dysk na wiekszy :))

  3. To oczywiste że FAT: , j23 9/01/07 12:02
    przeszukanie 2^12, czy 2^16 klastrów, z przyczyn oczywistych jest szybsze niż przeszukanie 2^32. Dlatego FAT jest szybszy (w czasach dostępu, transfer dużych plików od tego mniej zależy, choć im klastry są większe, tym transfer szybszy) od FAT32. NTFS jest od KAŻDEGO FAT wolniejszy przy małej ilości plików w katalogu (czyli prawie zawsze, bo mało kto ma kilkadziesiąt tys. plików w 1 katalogu), bo jest systemem plików z księgowaniem. KAŻDY system z księgowaniem jest wolniejszy od systemu bez księgowania, bo musi wzlędem tego drugiego przed i po transferze danych wykonać dodatkowe czynności związane z księgowaniem. Przewaga NTFS przy dużej ilości plików wynika jedynie z nieefektywnego wyszukiwania plików w FAT. FAT jedzie po liście plików z góry na dół i dostęp do plików zależy od ich pozycji w katalogu (te na końcu mają najgorsze czasy) i od długości listy. NTFS ma bardziej zaawansowany algorytm przeszukiwania listy plików. Ale różnice są widoczne tylko przy bardzo dużej ilości plików.

    Dumny nosiciel moherowego beretu!
    Me gustan tomar mis copas
    Żubrówka es lo mejor!

    1. zgadzam się ale radzę potestować , Master/Pentium 9/01/07 20:36
      bo przewaga NTFS ujawnia się już przy niższych ilościach plików niż kilkanaście tysięcy w jednym katalogu. Zresztą FAT jest zrobiony tak ułomnie, że nawet cześć systemów plików z linuksa (z księgowaniem) jest od niego szybsza.

      Nie ma tego złego , co by się w gorsze
      obrócić nie mogło - jak nie wierzysz
      włącz komputer :-)

  4. hmmm trzecia droga: , piszczyk 9/01/07 19:48
    http://www.xptruepower.cba.pl/...0vs%20FAT32-1.php
    czyli NTFS :)

    Gdy kupilem dysk przenosny 60GB na USB2.0 (WD Passport II) to bylem zniechecony jego predkoscią (max. 16MB/s). Okazalo sie, ze domyslnie byl sformatowany w FAT32. Po konwersji na NTFS predkosc przy odczycie skoczyla do... 28MB/s. Tak po prostu :).
    Ale najwiekszy "dopał" dala konwersja na NTFS pendrive'a Kingstona 256MB. Przy FAT32 kasowanie np. kilkudziesieciu plikow z zapchanego pen'a bylo bardzo wolne. Po konwersji na NTFS - jak ręką odjął, kasuje błyskiem :)

    Pzdr!

    takie tam klamoty . . .

    1. przytoczony artykuł to niestety bełkot , j23 9/01/07 20:45
      w którym zamiast testów, jest propagandowy chłam WPROST ze stron Microsoftu o NTFS (gdzie testów oczywiście NIE MA). To zresztą nie dziwi, bo zamieszczanie testów bez zgody Microsoft jest... nielegalne! Nie neguję, że osobiście mogłeś osiągnąć na swoim hd takie wyniki jak podałeś. Pytanie tylko skąd się wzięły. A wzięły się być może z polityki M$, który chce wprost na siłę zmusić do stosowania NTFS (licencjonowany. Patent na FAT wygasł i producenci pendrivów mogą go stosować za darmo). Wszyscy wiemy, jakie SZTUCZNE ograniczenia co do wielkości partycji FAT zastosował M$ w windach > Me. I tu pytanie: czy sterowniki windy jednakowo traktują oba systemy. Czy winda zakłada jednakowy cache dla obu systemów? I czy na innych, niż wspomniany HD, też są takie wyniki? Było by ciekawie ten sam HD podpiąć pod Win98, 2k i XP i porównać wyniki na FAT i NTFS... Taka ciekawostka z Linuksa: kiedyś postanowiono ujednolicić sterowniki w jajku dla flash i hd. Okazało się, że psują... flasha! Zrobiono (prawidłowo z zaleceniem FAT) tak, że po każdej operacji aktualizowano tablicę alokacji, bez jej cachowania, by była zawsze aktualna. Niestety flash wytrzymuje w jednym miejscu ok. 1 mln zapisów i pamięć siadała. Przywrócono poprzednie rozwiązanie z tablicą alokacji w cache i okresowym synchronizowaniu-sterownik był i dużo szybszy i nie niszczył flasha. Drobna rzecz, a drastyczne różnice w wynikach...

      Testowanie systemu plików to BARDZO TRUDNE działanie, o czym Twój artykuł się nie zająknął. Bardzo dobrze jest to opisane na różnych stronach linuksowych, bo Linux stosuje wiele systemów plików, więc jest duży wybór i naprawdę DUŻY dylemat co wybrać. Porównanie transferu i czasu dostępu MÓWI NIEWIELE: inaczej się to przedstawia dla małych plików (to najtrudniejsze-bezkonkurencyjny jest RaiserFS), inaczej duże pliki (najszybszy jest XFS). Inaczej się ma sprawa przy dużym obciążeniu I/O (serwery), inaczej na desktopach. Nie mniej ważne jest, że system może być szybki, ale za to mocno obciążać procesor (np. RaiserFS), przez co staje się nie do zaakceptowania w pewnych zastosowaniach. Na tych stronach jest też porównawczo NTFS i FAT. KAŻDY system bez księgowania (FAT, ext2) przy małej ilości plików BIJE NA GŁOWĘ systemy z księgowaniem!

      Na małej partycji systemowej Windy, OS zwykle używa MAŁYCH plików, zwykle dużo mniejszych od MB (konfiguracyje liczy się zwykle w kB!). Tu narzut związany z księgowaniem JEST WIELOKROTNIE DŁUŻSZY niż sam transfer plików! W testach transferu małych plików FAT bywa wydajniejszy od NTFS nawet o 40%!

      We wspomnianym artykule gdy czytam jak to autor się zamartwia jak to w biednym FAT dysk musi skakać z początku HD (tablica alokacji) na koniec i czy ktoś sobie wyobraża co to będzie jakby dysk miał 100GB, to odechciewa mi się dalej czytać takich bredni. Po pierwsze, FAT to pierwsza rzecz, jaka trafia do cache i to nawet nie w kompie, czy na sterowniku, ale wprost na HD, więc głowica wcale nie musi tak skakać. Ma mniej do skakania niż przy NTFS, gdzie tablic jest wiele, więc może ich nie być w cache! Po drugie, myślący(?) "linearnie" autor artykułu chyba sobie nie zdaje sprawy, że przy 3.5" dysku, z początku na koniec dysku głowica ma TAKI SAM DYSTANS do przeskoczenia, obojętnie czy HD ma 250GB, czy też jest to 20MB zabytek z przed 20 lat!!! Bardziej autor powinien się martwić tym, że przy systemie z księgowaniem, system plików NAJPIERW w dzienniku musi sprawdzić czy wszystko jest OK, potem zapisać co chce zrobić, wykonać operację i zaktualizować tablicę alokacji (system bez księgowania wykonuje tylko tą jedną operację!!!), zapisać w dzienniku że wszystko jest OK. Jest bezwzlędnie oczywiste, że dla małych plików samo ksiągowanie trwa dlużej niż cała operacja plikowa na systemie plików bez księgowania!!!

      Oczywiście FAT nie ma przyszłości (z wyj. małych napędów gdzie JEST SZYBSZY) bo nie ma kontroli uprawnień, księgowanie jest bezwzlędnie konieczne przy dużych napędach (skanowanie dużych HD trwa wieki), FAT ulega fragmentacji i przy wieloużytkownikowych systemach obsługa transakcji jest w zasadzie koniecznością, a jego system wyszukiwania plików jest wysoce nieefektywny przy ich dużej ilości.

      Oczywiście są systemy bez księgowania, jak FAT, ale pozbawione większości jego wad, np. ext2-nie ulegają defragmentacji, też mają rozproszone przechowywanie info o alokacji plików, zapewniają kontrolę uprawnień do pliku i wydajniejsze metody wyszukiwania plików. Są też oczywiście DUŻO szybsze przy małych plikach, od systemów z księgowaniem. Ale też odchodzą na emeryturę właśnie z uwagi na długi czas skanowania HD i mniejsze bezpieczeństwo operacji dyskowych z uwagi na brak księgowania.

      Dumny nosiciel moherowego beretu!
      Me gustan tomar mis copas
      Żubrówka es lo mejor!

      1. hmmm , piszczyk 9/01/07 22:52
        czy chcesz przez to powiedziec, ze moje WinXP po podlaczeniu dysku sformatowanego w FAT32 automatycznie i celowo go spowalnia, natomiast gdy go skonwertowalem na NTFS to ten "filtr" zostal natychmiast zdjety??

        takie tam klamoty . . .

        1. Nie musi być filtr: , j23 10/01/07 10:36
          wystarczy że do FAT np. winda nie udostępnia cache, albo stery do FAT mają mniejsze uprzywilejowanie w kernelu od NTFS. A jak dasz NTFS, to używają cache i uprzywilejować reszty systemu. Bardzo mnie ciekawi, jak ten sam HD zachowywał by się właśnie z Win98 i FAT. Bo od strony założeń, przy małej ilości plików, szczególnie małych plików, FAT MUSI być szybszy. Całkiem też możliwe, że gdybyś system miał na FAT i podłączał zewnętrzny dysk na NTFS, to właśnie NTFS nie miałby cache, bo być może (nie znam się na windzie) winda prowadzi tylko jeden cache, na główny system plików i wtedy ten dysk zewnętrzny własnie na NTFS byłby pokrzywdzony...

          Dumny nosiciel moherowego beretu!
          Me gustan tomar mis copas
          Żubrówka es lo mejor!

          1. rzeczywistość jest ciut skomplikowana , Master/Pentium 10/01/07 11:20
            1. Windows XP domyślnie nie buforuje (lub "słabo" buforuje) operacje na pendrivach. Dzięki temu można je wyjąć zaraz po zapisie nie tracąc danych. W przypadku 98/2000 domyślnie wszystko jest buforowane i wtedy wyjęcie pendrive bez zatrzymaj urządzenie="kaszana w systemie plików"
            2. Windows XP chyba grupuje operacje zapisu (tzn, że jednak jakiś elementarny bufor jest) na pendrive.
            3. Siłą rzeczy operacje lepiej grupuje się na NTFS (kilka tablic ale o charakterze bazy danych). Tablica FAT BEZNADZIEJNIE uaktualnia się na nośnikach typu pendrive bez sensownego buforowania/grupowania zapisów. Jest z uwagi na charakter zapisu (nośnik uaktualnia się wewnętrznie grupach po 64 kB itp.)

            Jednak taka różnica jak wspomniana powyżej jest podejrzana. Chyba że dotyczy małych plików. Bowiem procedury odczytu małych plików na FAT w wykonaniu MS są delikatnie mówiąc do d... .
            Kasowanie na NTFS jest dużo szybsze (transakcje).
            Swoją drogą kasowanie w ReiserFS też jest nieszczególne (i fajnie zapycha CPU ;) ).

            Nie ma tego złego , co by się w gorsze
            obrócić nie mogło - jak nie wierzysz
            włącz komputer :-)

            1. tez bylem zaskoczony taką różnicą , piszczyk 11/01/07 11:03
              tym bardziej, ze bylo to przy kopiowaniu wlasnie duzych plikow :|
              PS. Sprawdzalem to na dwoch komputerach i na obydwu tendencja byla podobna. Mialem juz nawet reklamowac ten dysk, ale proba z NTFS oszczedzila mi kombinacji :)

              takie tam klamoty . . .

    
All rights reserved ® Copyright and Design 2001-2024, TwojePC.PL