1.) Defragmentacja dysku SSD. 2.) Dysk SSD a program MHDD.
Latet
Wiem, �e dysk�w SSD nie powinno si� defragmentowa�, bo po pierwsze skraca to ich
�ywot, a po drugie - fragmentacja plik�w na takim dysku nie jest dla u�ytkownika
uci��liwa z wiadomych powod�w.
Ale tak si� zastanawiam - gdy po d�u�szym okresie u�wania dysk systemowy (SSD)
b�dzie ju� naprawd� bardzo mocno pofragmentowany, to mo�e jednak raz na p� roku
zapuszczenie defragmentacji nie jest takim z�ym pomys�em i mo�e nawet poprawi
wydajno��? Czasy dost�pu, cho� bardzo kr�tkie, nie s� przecie� zerowe...
Jak s�dzicie?
P.S.
Dlaczego narz�dzie MHDD (dos-owe) pokazuje g�upoty podczas skanowania dysku SSD?
Np. skanowanie trwa 30 sek. (zamiast �adnych paru minut), a wy�wietlona �rednia
pr�dko�� odczytu wynosi np. 1700 MB/s (prawie 10x szybciej, ni� jest naprawd�).
Pewnie ten program wykonuje jaki� szczeg�lny rodzaj odczytu sektor�w z pomiarem
czasu odczytu - ale czemu na SSD to nie dzia�a?
Dzi�ki,
latet
Rafał Łukawski
> Witam,
>
> Wiem, że dysków SSD nie powinno się defragmentować, bo po pierwsze
> skraca to ich żywot, a po drugie - fragmentacja plików na takim dysku
> nie jest dla użytkownika uciążliwa z wiadomych powodów.
>
> Ale tak się zastanawiam - gdy po dłuższym okresie użwania dysk systemowy
> (SSD) będzie już naprawdę bardzo mocno pofragmentowany, to może jednak
> raz na pół roku zapuszczenie defragmentacji nie jest takim złym pomysłem
> i może nawet poprawi wydajność? Czasy dostępu, choć bardzo krótkie, nie
> są przecież zerowe...
>
> Jak sądzicie?
Aby na to jednoznacznie odpowiedziec warto wziac pod uwage jeden istotny
wskaznik - sredni transfer z dysku. Z tego co mi wiadomo testy w miarę
zbliżone do rzeczywistości przeprowadza 3dMark Vantage, jeżeli transfer
z dysku bez fragmentacji bedzie -+5% w porównaniu z mocno
fragmentowanym, to nie warto zawracac sobie glowy. Nie wiem czy ktoś
robił takie porównania.
Z technicznego pkt. widzenia warto w realnych testach uwzględnić ilość
operacji kasowania bloków na SSD przy określonych zadaniach w porównaniu
do dysku 'liniowego' i zfragmentowanego, ale tu już zaczyna się filozofia..
--
Western Digital Silver Partner - http://luktronik.pl/
Jerzy Dombczak
>
> Wiem, że dysków SSD nie powinno się defragmentować, bo po pierwsze
> skraca to ich żywot, a po drugie - fragmentacja plików na takim dysku
> nie jest dla użytkownika uciążliwa z wiadomych powodów.
>
> Ale tak się zastanawiam - gdy po dłuższym okresie użwania dysk systemowy
> (SSD) będzie już naprawdę bardzo mocno pofragmentowany, to może jednak
> raz na pół roku zapuszczenie defragmentacji nie jest takim złym pomysłem
> i może nawet poprawi wydajność? Czasy dostępu, choć bardzo krótkie, nie
> są przecież zerowe...
>
> Jak sądzicie?
>
> Dlaczego narzędzie MHDD (dos-owe) pokazuje głupoty podczas skanowania
> dysku SSD? Np. skanowanie trwa 30 sek. (zamiast ładnych paru minut), a
> wyświetlona średnia prędkość odczytu wynosi np. 1700 MB/s (prawie 10x
> szybciej, niż jest naprawdę). Pewnie ten program wykonuje jakiś
> szczególny rodzaj odczytu sektorów z pomiarem czasu odczytu - ale czemu
> na SSD to nie działa?
>
> Dzięki,
>
> latet
>
>
Pisalem juz o tym kilka razy dyskow SSD sie nie defragmentuje.
Wewnetrzna struktura danych zapisanych w pamieci NAND ma sie nijak do
tego co widzi windows, wynika to ze sposobu zapisu pamieci NAND przez
kontroler SSD ktory tlumaczy wewnetrzny zapis na odczytywalny przez
system operacyjny.
Hektor
> Ale tak się zastanawiam - gdy po dłuższym okresie użwania dysk systemowy
> (SSD) będzie już naprawdę bardzo mocno pofragmentowany, to może jednak raz
> na pół roku zapuszczenie defragmentacji nie jest takim złym pomysłem i
> przecież zerowe...
Nie wdajac sie w szczególy, "fragmentacja" w dyskach typu SSD jest zupelnie
bez znaczenia. Zapuszczenie jakiegokolwiek programu defragmentujacego
niczego tu nie zmieni (na lepsze).
ZK
Piotr "Charvel" Majka
> Witam,
>
> Wiem, że dysków SSD nie powinno się defragmentować, bo po pierwsze
Sergiusz Rozanski
Z tą defragmentacją SSD to nie do końca taka prawda jak piszecie, bo
SSD też się fragmentuje i to ma wpływ na jego szybkość. Przy czym
defragmentacja aplikacją ze systemu operacyjnego na nic się nie zda.
Dysk sam dba o uniknęcie poniżej opisanej fragmentacji - ale algorytmy
tego są różne i nie zawsze skuteczne.
Uwaga będzie głęboko: dysk ssd jest podzielony na bloki nie po 512B
ale po 4,8 itd kB. Z pamięci flash odczytywany jest więc taki niepodzielny
blok i z niego wyłuskiwany sektor 512B akurat potrzebny do wysłania.
I teraz dajmy na to mamy duży plik który zajmuje nam 0.5GB czyli
~milion sektorów. A sam dysk mamy tak poszatkowany że akurat każda z
jego części zapisała się w innym bloku np 8kB. Oznacza to że aby wysłać
przez sata te 0.5GB trzeba odczytać z flasha 16x tyle danych! czyli
8GB. Szybkość w takim przypadku liniowego odczytu (wewnętrznego) spadnie
16-sto krotnie do oczekiwanych i zapewne będzie odczuwalna na sata.
januszek
> Z tą defragmentacją SSD to nie do końca taka prawda jak piszecie, bo
> SSD też się fragmentuje i to ma wpływ na jego szybkość.
ich dzialania. Jest kilka innych problemow, zwiazanych z konstrukcja
SSD, ktore moga prowadzic z czasem do spadku wydajnosci ale zaden z tych
powodow nie jest zwiazany z fragmentacja plikow...
j.
--
http://www.predkosczabija.pl/
"Prędkość zabija. Włącz myślenie!"
Tomasz Jasiński
doszła do mnie wiadomość <j67ur2$ag7$1...@inews.gazeta.pl>
od "Latet" <la...@latet.pl> :
>Witam,
>
>żywot, a po drugie - fragmentacja plików na takim dysku nie jest dla użytkownika
>uciążliwa z wiadomych powodów.
>
>będzie już naprawdę bardzo mocno pofragmentowany, to może jednak raz na pół roku
>zapuszczenie defragmentacji nie jest takim złym pomysłem i może nawet poprawi
>
>Jak sądzicie?
dysku.
Najbardziej skuteczny będzie backup -> secure erase -> restore.
Inna metoda(już nie tak skuteczna) to wymuszenie TRIM na wolnej
przestrzeni dysku(jeśli na dysku masz XP czy system nie obsługujący
TRIM), można to zrobić z systemu obsługującego TRIM(np Win 7),
podłączasz taki dysk do komputera z win7, tworzysz na nim jeden wielki
plik z losową zawartością po czym go usuwasz.
Jeśli ktoś ma wiele systemów(np XP i Windows 7) to może to zrobić spod
Windows 7.
>P.S.
>Dlaczego narzędzie MHDD (dos-owe) pokazuje głupoty podczas skanowania dysku SSD?
>Np. skanowanie trwa 30 sek. (zamiast ładnych paru minut), a wyświetlona średnia
>prędkość odczytu wynosi np. 1700 MB/s (prawie 10x szybciej, niż jest naprawdę).
>czasu odczytu - ale czemu na SSD to nie działa?
>
Ja mam tak na kartach CF podłączanych przez expresscard cf reader
Lexara, to może być zarówno kwestia sprzętu jak i sterownika do niego.
>Dzięki,
>
>latet
>
--
Penne Rigate will spontaneously insert itself into Rigatoni
(order pasta) under liquid to gas transition conditions
of H2O to create the previously unobserved species
Noodleous doubleous. The estimated probability of this
spontaneous generation event is too low to be explained
by thermodynamics and therefore apparently represents
intelligent design.
Thomas D. Schneider, Ph.D. Frederick, MD
Andrzej Lawa
> Uwaga będzie głęboko: dysk ssd jest podzielony na bloki nie po 512B
> ale po 4,8 itd kB. Z pamięci flash odczytywany jest więc taki niepodzielny
> blok i z niego wyłuskiwany sektor 512B akurat potrzebny do wysłania.
> I teraz dajmy na to mamy duży plik który zajmuje nam 0.5GB czyli
> ~milion sektorów. A sam dysk mamy tak poszatkowany że akurat każda z
> jego części zapisała się w innym bloku np 8kB. Oznacza to że aby wysłać
> przez sata te 0.5GB trzeba odczytać z flasha 16x tyle danych! czyli
> 8GB. Szybkość w takim przypadku liniowego odczytu (wewnętrznego) spadnie
> 16-sto krotnie do oczekiwanych i zapewne będzie odczuwalna na sata.
512-bajtowe klastry.
Andrzej Lawa
> Wiem, że dysków SSD nie powinno się defragmentować, bo po pierwsze
> skraca to ich żywot,
Czasem dość drastycznie - to przecież ciągłe mielenie cyklami zapisu i
kasowania.
> a po drugie - fragmentacja plików na takim dysku
> nie jest dla użytkownika uciążliwa z wiadomych powodów.
strukturą "pokazywaną" przez ten "dysk" systemowi operacyjnemu.
> Ale tak się zastanawiam - gdy po dłuższym okresie użwania dysk systemowy
> (SSD) będzie już naprawdę bardzo mocno pofragmentowany, to może jednak
> raz na pół roku zapuszczenie defragmentacji nie jest takim złym pomysłem
> i może nawet poprawi wydajność? Czasy dostępu, choć bardzo krótkie, nie
> są przecież zerowe...
Latet
> przestrzeni dysku(jeśli na dysku masz XP czy system nie obsługujący
> TRIM), można to zrobić z systemu obsługującego TRIM(np Win 7),
> podłączasz taki dysk do komputera z win7, tworzysz na nim jeden wielki
> plik z losową zawartością po czym go usuwasz.
chwilę przez ten jeden wielki plik jest faktycznie trimowana. O wiele
skuteczniejsze jest wypełnienie całej wolnej przestrzeni dużą ilością małych
plików i skasowanie ich. Wtedy zwykle (nie zawsze) prawa cała taka przestrzeń
zostaje faktycznie strimowana. Przynajmniej tak się dzieje na moim OCZ Vertex 2.
latet
Latet
> 512-bajtowe klastry.
Testowałem większe klastry, ale nie zauważyłem wzrostu wydajności.
Oczywiście wiem, że inną kwestią jest prawidłowy "aligment" partycji, a inną
wielkość klastra wybrana podczas formatowania.
latet
MC
napisał w wiadomości
news:slrnj8k05a.d9m.wr...@dns.media-lab.com.pl...
> Uwaga będzie głęboko: dysk ssd jest podzielony na bloki nie po 512B
> ale po 4,8 itd kB. Z pamięci flash odczytywany jest więc taki niepodzielny
> blok i z niego wyłuskiwany sektor 512B akurat potrzebny do wysłania.
> I teraz dajmy na to mamy duży plik który zajmuje nam 0.5GB czyli
> ~milion sektorów. A sam dysk mamy tak poszatkowany że akurat każda z
> jego części zapisała się w innym bloku np 8kB. Oznacza to że aby wysłać
> przez sata te 0.5GB trzeba odczytać z flasha 16x tyle danych! czyli
> 8GB. Szybkość w takim przypadku liniowego odczytu (wewnętrznego) spadnie
> 16-sto krotnie do oczekiwanych i zapewne będzie odczuwalna na sata.
postanowiło rozwiązać nieistniejący problem?
MC
news:j6dfel$3uh$1...@inews.gazeta.pl...
mają nic wspólnego z rzeczywistością. Kontroler SSD sam rządzi tym wszyskim.
Latet
> mają nic wspólnego z rzeczywistością. Kontroler SSD sam rządzi tym wszyskim.
Sprawdziłem.
latet
MC
jest po prostu z definicji niemożliwy.
qwerty
dyskusyjnych:j6dfel$3uh$1...@inews.gazeta.pl...
> Testowałem większe klastry, ale nie zauważyłem wzrostu wydajności.
sekund szybciej.
qwerty
> chwilę przez ten jeden wielki plik jest faktycznie trimowana. O wiele
> skuteczniejsze jest wypełnienie całej wolnej przestrzeni dużą ilością małych
> plików i skasowanie ich. Wtedy zwykle (nie zawsze) prawa cała taka przestrzeń
> zostaje faktycznie strimowana. Przynajmniej tak się dzieje na moim OCZ Vertex
> 2.
ciągle wolną przestrzeń losowymi bitami (zapisywanie, kasowanie, zapisywanie
itd.) i patrzeć jak SSD zdycha.
januszek
> Lepiej zapchać prawie cały dysk (zostawiając 0,5 GiB wolnego miejsca). Zapisywać
> ciągle wolną przestrzeń losowymi bitami (zapisywanie, kasowanie, zapisywanie
> itd.) i patrzeć jak SSD zdycha.
qwerty
dyskusyjnych:slrnj8osjf.2...@gimli.mierzwiak.com...
> Dlaczego zdycha?
Ile komórki dają radę się zapisać? 1 mln? Załóżmy, że jest nadpisywany co 2
sekundy. W 23 dni uśmiercasz dysk.
Latet
>> ogromne. Sprawdziłem.
>
> To jakiś przypadkowy wynik, jak w wielu twoich sprawdzianach. Taki związek
> jest po prostu z definicji niemożliwy.
przypadku! Testy powtarzam wiele wiele razy (dlatego niżej podaję przedziały
wyników: min-max) w dość dobrze kontrolowanych warunkach. Różnica w wynikach
między LBA-63 a LBA-2048 stanowczo za duża, aby był to przypadek.
AS SSD 4KB-Write:
LBA-2048: 45,3 - 56,7 MB/s
LBA-63: 11,8 - 11,9 MB/s
AS SSD 4KB 64-Thread -Write:
LBA-2048: 46,2 - 62,9 MB/s
LBA-63: 12,3 - 13,2 MB/s
Crystal Disk Mark 4K Write:
LBA-2048: 38,5 - 64,3 MB/s
LBA-63: 8,1 - 10,7 MB/s
Crystal Disk Mark 4K Q32 Write:
LBA-2048: 29,8 - 65,1 MB/s
LBA-63: 8,0 - 11,3 MB/s
Natomiast w zapisie sekwencyjnym oraz we wszystkich testach odczytu - różnicy
rzeczywiście nie ma.
Zresztą - kto nie wierzy, niech sam sprawdzi, a nie teoretyzuje.
latet
Latet
>> Testowałem większe klastry, ale nie zauważyłem wzrostu wydajności.
>
> Na SSD, czy HDD? U mnie po zmianie z 4 KiB, na 64 KiB system wstaje o kilka
> sekund szybciej.
Zresztą mój SSD ma tylko 60GB, więc naprawdę za wiele miejsca nie ma, aby
stosować duży klaster (wszak system to bardzo dużo małych plików).
latet
Latet
>> chwilę przez ten jeden wielki plik jest faktycznie trimowana. O wiele
>> skuteczniejsze jest wypełnienie całej wolnej przestrzeni dużą ilością małych
>> plików i skasowanie ich. Wtedy zwykle (nie zawsze) prawa cała taka przestrzeń
>> zostaje faktycznie strimowana. Przynajmniej tak się dzieje na moim OCZ Vertex
>> 2.
>
> Lepiej zapchać prawie cały dysk (zostawiając 0,5 GiB wolnego miejsca).
> Zapisywać ciągle wolną przestrzeń losowymi bitami (zapisywanie, kasowanie,
> zapisywanie itd.) i patrzeć jak SSD zdycha.
Poza tym, sposób, który opisałeś mógłby szybko "zabić" urządzenie wyposażone w
"dynamic wear leveling", natomiast dyski SSD mające "static wear leveling"
potrafiłyby się skutecznie bronić.
Cytuję WIKI:
The first type of real leveling is called dynamic wear leveling and it uses a
map to link Logical Block Addresses (LBAs) from the OS to the physical Flash
memory. Each time the OS writes replacement data, the map is updated so the
original physical block is marked as invalid data, and a new block is linked to
that map entry. Each time a block of data is re-written to the Flash memory it
is written to a new location. However, blocks that never get replacement data
sit with no additional wear on the Flash memory. The name comes from only the
dynamic data is being recycled. The drive may last longer than one with no wear
leveling, but there are blocks still remaining as active that will go unused
when the drive is no longer operable.
The other type of wear leveling is called static wear leveling which also uses a
map to link the LBA to physical memory addresses. Static wear leveling works the
same as dynamic wear leveling except the static blocks that do not change are
periodically moved so that these low usage cells are able to be used by other
data. This rotational effect enables the SSD to operate until most of the blocks
are near their end of life.[2][3]
http://en.wikipedia.org/wiki/Wear_leveling
januszek
> Ile komórki dają radę się zapisać? 1 mln? Załóżmy, że jest nadpisywany co 2
> sekundy. W 23 dni uśmiercasz dysk.
kontroli nad tym która konkretnie komórka zostanie zapisana bo o to dba
kontroler, który rozkłada to mniej więcej równomiernie po wszystkich
komórkach dysku. Stąd wynika właśnie łatwo obserwowany spadek wydajności
w sytuacji kiedy na dysku nie ma dużego zapasu wolnego miejsca.
Na szybko zrobilem test na dysku, ktory akurat mialem pod ręką. Zobacz:
http://gimli.beerman.eu.org/~kezu/ssd-test.jpg
Dysk SSD 90GB:
- 1 - 70GB zajete,
- 2 - ok 90GB zajete,
- 3 - znowu 70GB zajete.
Rafał
qwerty wrote:
> UĹźytkownik "januszek" napisaĹ w wiadomoĹ ci grup
> dyskusyjnych:slrnj8osjf.2...@gimli.mierzwiak.com...
> > Dlaczego zdycha?
>
> Ile komĂłrki dajÄ radÄ siÄ zapisaÄ ? 1 mln? ZaŠóşmy, Ĺźe jest nadpisywany co 2
> sekundy. W 23 dni uĹ miercasz dysk.
zagalopowałeś się!
Komórki zapisywane są idąc od początku do końca i tak w kółko.
Równomiernie.
Ile czasu potrzeba za zapisanie całego dysku?
Dysk jest szybki, ale z 5 min na pewno.
5 min x 1.000.000 i wyjdzie ci teoretyczny czas potrzebny za załatwienie
całego dysku.
Jeśli będziesz chciał załatwić fragment, to też ci zejdzie, bo z zwykle 5%
dysku zarezerwowane jest za podmianę. Czyli jak coś padnie, to z tych 5%
sie podbierze i nawet nie bedziesz o tym wiedział.
Słowem na pierwszy efekt trzeba naprawdę długo pracować.
Myśle, że rok. Przy normalnej pracy dysk powinien wytrzymać 5 lat!
Po 5 latach i tak kupisz nowy :)
Jeśli będzie dbał o dysk, czyli temy na innym dysku, swap też,
to możesz być pokojny.
Latet
> http://gimli.beerman.eu.org/~kezu/ssd-test.jpg
>
> Dysk SSD 90GB:
> - 1 - 70GB zajete,
> - 2 - ok 90GB zajete,
> - 3 - znowu 70GB zajete.
zapisanych danymi oraz strimowanych. Różnica charakterystyczna dla chipsetów
Sandforce - które wykorzystują kompresję danych w locie do przyśpieszenia
transferów.
latet
Latet
> to możesz być pokojny.
odczuwalnie spowalnia codzienną pracę (tempy i swap) nie będzie się na nim
trzymać?
Ja tam trzymam - i jedno i drugie. Bacznie obserwuję w smart liczniki
odczytanych i zapisanych danych. Odkąd skończyłem testy, a zacząłem normalne
użytkowanie dysku (jako systemowego) - liczniki te rosną znacznie wolniej, niż
sądziłem, a ZWLASZCZA licznik danych zapisanych. Zapisuje się coś w granicach
0,1 GB na tydzień! (z tym że wszystkie foldery typu "Moje Dokumenty" mam na
innym dysku, a wielkość pliku swap wynosi tylko 250 MB).
Oczywiscie - najchętniej i tempy i swapa wrzuciłbym na jakiś ramdysk, ale nie
znam prostej i wygodnej metody zrobienia tego.
latet
Rafał
Latet wrote:
> > Jeśli będzie dbał o dysk, czyli temy na innym dysku, swap też,
> > to możesz być pokojny.
>
> Tylko jaki jest sens kupna szybkiego dyski SSD, jesli to, co najbardziej
> odczuwalnie spowalnia codzienną pracę (tempy i swap) nie będzie się na nim
> trzymać?
System Win7 na moim HDD ładował się w 28 s , a SSD 12s
a tempy i swap mam na HDD
na początku miałem na SSD i równica była ledwo zauważalna,
żeby nie powiedzieć pomijalna
Fakt, faktem że swap wykorzystuje w 5%, tak wiec systemem
niewiele go tyka, a tempy... najwiecej powstają gdy przeglądamy
strony www. To wszystko jest wolne z definicji, więc SSD nie wiele
tutaj daje. Słowem to może być na HDD.
Latet
>> odczuwalnie spowalnia codzienną pracę (tempy i swap) nie będzie się na nim
>> trzymać?
>
> nie masz racji, bo to nie jest najbardziej odczuwalne.
> System Win7 na moim HDD ładował się w 28 s , a SSD 12s
> a tempy i swap mam na HDD
systemu.
A czas otwierania FF, czy IE - drastycznie mi się skrócił, odkąd ich tempy leżą
na SSD.
> To wszystko jest wolne z definicji, więc SSD nie wiele
> tutaj daje. Słowem to może być na HDD.
A właśnie rzeczy wolne z definicji najbardziej zyskują na przeniesieniu
hdd-->ssd.
latet
Rafał
> >> Tylko jaki jest sens kupna szybkiego dyski SSD, jesli to, co najbardziej
> >> odczuwalnie spowalnia codzienną pracę (tempy i swap) nie będzie się na nim
> >> trzymać?
> >
> > nie masz racji, bo to nie jest najbardziej odczuwalne.
> > System Win7 na moim HDD ładował się w 28 s , a SSD 12s
> > a tempy i swap mam na HDD
>
> Akurat tempy przeglądarek raczej nie mają wiele wspólnego z czasem ładowania się
> systemu.
i nie do końca go wykorzystywać (w sensie, tempy i swap mieć na HDD)
>
> A czas otwierania FF, czy IE - drastycznie mi się skrócił, odkąd ich tempy leżą
> na SSD.
>
> > To wszystko jest wolne z definicji, więc SSD nie wiele
> > tutaj daje. Słowem to może być na HDD.
>
> Pewnie, że może. Przez ostatnie 20 lat było i jakoś żyliśmy ;-)
> A właśnie rzeczy wolne z definicji najbardziej zyskują na przeniesieniu
> hdd-->ssd.
>
Ale też z tego powodu, iż nie chcę mieć śmieci na dysku systemowym,
bo często robię kopie (obraz) systemowego dysku a tym przypadku kopiowanie
śmieci to tylko strata czasu i miejsca na dysku, na który obraz dysku systemu
jest kopiowany.
Hektor
>> Akurat tempy przeglądarek raczej nie mają wiele wspólnego z czasem
>> ładowania się
>> systemu.
>
> ale ja tego nie napisałem. Wskazuje tylko, że już dla tego efektu warto
> mieć SSD
> i nie do końca go wykorzystywać (w sensie, tempy i swap mieć na HDD)
sensu. Chcesz sie nim cieszyc do poznej starosci? I tak za jakis czas
bedziesz go zmienial. Ja takze potwierdzam, ze przeniesienie katalogów
tymczasowych na dysk SSD dodaje przegladarkom (i wszelkim programom
intensywnie uzywajacym tempów) duzych skrzydel. Wlasnie po to kupilem taki
dysk, aby widziec efekty jego sprawnosci na kazdym kroku a nie tylko podczas
ladowania i gaszenia systemu. Ogladanie statystyk zapisów i kalkulowanie na
ile jeszcze dziesiatków lat wystarczy mi ten dysk jest pomyslka. Lepiej od
razu polozyc go na polke i co wieczór zachwycac sie jego teoretyczna
wydajnoscia.
ZK
MC
>>> ogromne. Sprawdziłem.
>>
>> To jakiś przypadkowy wynik, jak w wielu twoich sprawdzianach. Taki
>> związek jest po prostu z definicji niemożliwy.
>
> Różnica jest spora, ale dotyczy tylko zapisu w małych blokach. Nie ma mowy
> o przypadku! Testy powtarzam wiele wiele razy (dlatego niżej podaję
> przedziały wyników: min-max) w dość dobrze kontrolowanych warunkach.
> Różnica w wynikach między LBA-63 a LBA-2048 stanowczo za duża, aby był to
> przypadek.
Rafał Łukawski
>> warunkach. Różnica w wynikach między LBA-63 a LBA-2048 stanowczo za
>> duża, aby był to przypadek.
>
> Taak? A co to jest LBA w wypadku SSD?
hostem. Gdyby naped SSD nie obslugiwal LBA nie podlaczylbys go do
zadnego urzadzenia. ot co.
To jak to jest mapowane wewnatrz jest tak samo sensowne jak w przypadku
HDD, gdzie np. wystepuja reallokowane sektory, ale przeciez LBA o tym
nie wie (bo i po co).
--
Western Digital Silver Partner - http://luktronik.pl/
qwerty
dyskusyjnych:4E8CB053...@gazeta.pl...
> Komórki zapisywane są idąc od początku do końca i tak w kółko.
> Równomiernie.
> Ile czasu potrzeba za zapisanie całego dysku?
1. Zapełniasz cały dysk (zostawiając 0,5 GiB wolnego miejsca)
2. Tworzysz plik z losową zawartością i zapełniasz te 0,5 GiB
3. Kasujesz utworzony plik w punkcie 2
4. Go to 2.
Co mi pieprzysz o zapełnianiu całego dysku, skoro 99,9% danych nie jest
ruszanych?
Rafał
To przeczytaj jeszcze raz moją wypowiedź szczególnie
o tych zarezerwowanych 5%
Tak na spokojnie :)
qwerty
> To przeczytaj jeszcze raz moją wypowiedź szczególnie
> o tych zarezerwowanych 5%
> Tak na spokojnie :)
dysku 60 GB daje nam ok 160 dni.
Rafał
Tak wiec dopiero po pół roku możesz ujrzeć widoczny efekt
swojej 'pracy' czyli uszkodzenia dysku. Możesz, ale nie musisz,
bo producenci deklarują iż po tym milionie zapisów dysk
będzie jeszcze całkiem sprawny. Zresztą niektórzy producenci
gwarantują 2 mln cykli. Nie wiem jak wyliczyłeś to 160 dni,
ale przypadku 2 mln zajeżdżenie dysku trzeba pracować rok.
Dodam, że to będzie bardzo intensywna praca.
Aha, system NTFS też rezerwuje trochę miejsca dla siebie
i jeśli trafi na bad sektor to go odpisze i zastąpi ze swojej rezerwy
więc użytkownik znów jeszcze żadnego efektu uszkodzenia nie zobaczy :)
Takie testy były już przeprowadzane i z tego co słyszałem
nie udało się zajeździć dysku. Dyski padają i dość spory odsetek
np. OCZ Vertex 3 niestety z innego powodu, np. kontrolera.
lub tak jak czytam fora, z bliżej nie okreslonego powodu.
Np. pewnego pięknego dnia stają się niewidoczne i w tym jest
problem, niż samymi uszkodzeniami komórek.
Reasumując : kupić dysk i nie przejmować się. A jak ktoś chcę spać
spokojnie to temy i swap może przerzucic na HDD i też będzie się
cieszył dobrodziejstwami płynącymi z SSD
Tomasz Jasiński
doszła do mnie wiadomość <j6kfsh$hjr$1...@inews.gazeta.pl>
od "qwerty" <qwer...@poczta.fm> :
http://download.micron.com/pdf/technotes/nand/tn2942_nand_wear_leveling.pdf
--
Gdyby się wysadziło ich planety, zburzyło miasta,
spaliło księgi, a ich samych wytłukło do nogi,
może udałoby się ocalić naukę miłości bliźniego. SL.
januszek
> Umiesz czytać ze zrozumieniem, czy tylko udajesz debila?
> 1. Zapełniasz cały dysk (zostawiając 0,5 GiB wolnego miejsca)
> 2. Tworzysz plik z losową zawartością i zapełniasz te 0,5 GiB
> 3. Kasujesz utworzony plik w punkcie 2
> 4. Go to 2.
> Co mi pieprzysz o zapełnianiu całego dysku, skoro 99,9% danych nie jest
> ruszanych?
Czy sie to podoba czy nie. Musisz zupdateowac swoj dogmat ;P
MC
news:j6kbn0$d7j$1...@news.onet.pl...
>>> warunkach. Różnica w wynikach między LBA-63 a LBA-2048 stanowczo za
>>> duża, aby był to przypadek.
>>
>> Taak? A co to jest LBA w wypadku SSD?
>
> LBA jest sposobem adresowania na poziomie protokołu pomiędzy napędem a
> hostem. Gdyby naped SSD nie obslugiwal LBA nie podlaczylbys go do zadnego
> urzadzenia. ot co.
>
> To jak to jest mapowane wewnatrz jest tak samo sensowne jak w przypadku
> HDD, gdzie np. wystepuja reallokowane sektory, ale przeciez LBA o tym nie
> wie (bo i po co).
razem tej samej komórki pamięci. A więc testy kolegi są bez sensu.
Latet
> tej samej komórki pamięci. A więc testy kolegi są bez sensu.
http://www.ocztechnologyforum.com/forum/showthread.php?57599-RAID-Non-RAID-Partition-Alignment-for-max-performance
http://www.ocztechnologyforum.com/forum/showthread.php?48309-Partition-alignment-importance-under-Windows-XP-%2832-bit-and-64-bit%29..why-it-helps-with-stuttering-and-increases-drive-working-life.
http://forum.notebookreview.com/hardware-components-aftermarket-upgrades/350177-ssd-partition-alignment-offset.html
latet
MC
>> razem tej samej komórki pamięci. A więc testy kolegi są bez sensu.
>
> Polecam się najpierw podedukować, a potem wymądrzać:
> http://www.ocztechnologyforum.com/forum/>
> http://forum.notebookreview.com/hardwar
Szkoda, że nie rozumiesz znaczenia słowa forum. Nie mówiąc już o treści
samych wiadomości.
Latet
> wiadomości.
zapuść parę testów (np. As-SSD Bench*), potem załóż partycję od LBA2048, zapuść
te same testy, a potem porównaj wyniki. Powtórz całą procedurę tyle razy i Ci
potrzeba, aby przekonać samego siebie, że drastyczna różnica w wydajności zapisu
małych bloków, którą zobaczysz w wynikach testów, nie jest przypadkowa.
* - nawiasem mówiąc As-SSD wyświetla info o partition aligment - i jeśli jest
założona od LBA63, to krzyczy na czerwono "not OK".
latet.
Rafał
>
> * - nawiasem mĂłwiÄ c As-SSD wyĹ wietla info o partition aligment - i jeĹ li jest
> zaĹ oĹźona od LBA63, to krzyczy na czerwono "not OK".
>
a jakiej wersji As-SSD to jest?
Bo ja mam 1.6.4237 i jakoś tego nie widzę i przyznam się, że nie wiem jak sprawdzić
czy mam LBA63 czy coś innego
mam :
msahci - OK
103424 K - OK
o partition aligment ani słowa
J.F
> Ale tak się zastanawiam - gdy po dłuższym okresie użwania dysk
> systemowy
> (SSD) będzie już naprawdę bardzo mocno pofragmentowany, to może
> jednak
> raz na pół roku zapuszczenie defragmentacji nie jest takim złym
> pomysłem
> i może nawet poprawi wydajność? Czasy dostępu, choć bardzo krótkie,
> nie
> są przecież zerowe...
Czasy dostepu sa zasadniczo jednakowe, wiec tu zysk zaden.
No - moze jest jakas zauwazalna roznica jesli system moze odczytac
wieksza ilosc danych jednym ciagiem, bez wysylania adresow do dysku.
Nie wiem jaka jest organizacja NTFS - ale przy FAT moze byc pewnym
wydluzeniem fragmentacja w FAT.
Chcemy nastepny blok odczytac, a jego numer w innym sektorze FAT,
musimy go dopiero przeczytac ... i tu pytanie, czy system korzysta ze
swoich xxGB ram i trzyma FAT w pamieci czy nie :-)
Przy unixowej organizacji chyba bez znaczenia.
Natomiast ... jesli cos sie na dysku uszkodzi, to nie ma jak porzadny
dysk, gdzie pliki zajmuja ciagle obszary i mozna wszystko bez
problemow odzyskac .. tylko MS tego nie rozumie i burdel robi :-)
J.
Latet
To jest w właśnie informacja o partition aligment. Jeśli jest "OK" i zielony
kolor, to jest OK. W przeciwnym razie jest czerwone i pisze "BAD".
Wersję AS-SSD mam tę samą.
latet
Kicer
>
> My�lisz, �e po tych kom�rkach pami�ci jaka� g�owica lata? ;->
mniejsza o latanie, ale podejrzewam, �e elektronika wewn�trz umo�liwia
szybszy odczyt/zapis jesli transfer dotyczy kolejnych blok�w (chyba we
wszystkich urz�dzeniach od ram�w po hdd tak jest).
pozdrawiam
--
Michaďż˝ Walenciak
gmail.com kicer86
http://kicer.sileman.net.pl
gg: 3729519
Tom01
> mniejsza o latanie, ale podejrzewam, że elektronika wewnątrz umożliwia
> szybszy odczyt/zapis jesli transfer dotyczy kolejnych bloków (chyba we
> wszystkich urządzeniach od ramów po hdd tak jest).
Defragmentacja SSD to prosta droga do jego zniszczenia.
--
Tomasz Jurgielewicz
Masz ochotę zapytać mnie o monitory specjalistyczne?
Masz problem z kolorem? Wal śmiało!
monitory.mastiff.pl, gg: 189335, skype: zpkmastif
Kicer
> W dniu 08.10.2011 11:34, Kicer pisze:
>> mniejsza o latanie, ale podejrzewam, �e elektronika wewn�trz umo�liwia
>> szybszy odczyt/zapis jesli transfer dotyczy kolejnych blok�w (chyba we
>> wszystkich urz�dzeniach od ram�w po hdd tak jest).
>
> Defragmentacja SSD to prosta droga do jego zniszczenia.
>
nie powiedzia�em �e nie, chodzi mi jedynie o to �e dost�p sekwencyjny zawsze
jest szybszy.
To wlasnie jedyne co mnie powstrzymuje przed SDD, �e po prostu si� zu�ywaj�.
Rafał
> Tom01 wrote:
>
> > W dniu 08.10.2011 11:34, Kicer pisze:
> >> mniejsza o latanie, ale podejrzewam, �e elektronika wewn�trz umo�liwia
> >> szybszy odczyt/zapis jesli transfer dotyczy kolejnych blok�w (chyba we
> >> wszystkich urz�dzeniach od ram�w po hdd tak jest).
> >
> > Defragmentacja SSD to prosta droga do jego zniszczenia.
> >
>
> nie powiedzia�em �e nie, chodzi mi jedynie o to �e dost�p sekwencyjny zawsze
> jest szybszy.
> To wlasnie jedyne co mnie powstrzymuje przed SDD, �e po prostu si� zu�ywaj�.
>
a na ile lat kupuszesz sprz�t?
Bo je�li na 10-20 lat to masz racje, ale je�li na 5 to spoko SSD mo�e kupowa�
Latet
> jest szybszy.
> To wlasnie jedyne co mnie powstrzymuje przed SDD, �e po prostu si� zu�ywaj�.
Daj spok�j. Przyjemno�� z przesiadki z hdd na ssd rekompensuje wszelkie takie
obawy i troski. Naprawdďż˝ warto.
A zu�ywanie, cho� jest faktem, przebiega znacznie znacznie wolniej, ni� to sobie
wyobra�aj� ci, co si� tego boj�.
I jestem pewny, �e zanim m�j Vertex 2 (60GB) zd��y si� "zu�y�" to ju� dawno go z
w�asnej woli wymieni� na inny, szybszy, wi�kszy i lepszy.
P�ki co - u�ywam go bardzo intensywnie od 1,5 miesi�ca (na pocz�tku kilkana�cie
dni ci�kiego testowania, potem jako dysk systemowy z plikiem wymiany). I co? I
nic. Owszem, 1,5 miesi�ca to kr�tko, ale patrz� ta� na smart, a tam s� takie
wska�niki jak:
Retired Block Count - wci�� 0
Erase Fail Count - wci�� 0
Wear Range Delta - wciaďż˝ 0
Relocated Event Count - wciaďż˝ 0
SSD Life Left - wci�� "0" (czyli max. zak�adny czas - tj. do 4 grudnia 2019 wg.
SSDLife Free 2.1.29)
Licznik odczytanych danych ��cznie - 2904 GB (tj. prawie 3 TB!)
Licznik zapisanych danych ��cznie - 2700 GB
Jak wida� po ostatnim - zapisa�em ju� na ten dysk dane o ��cznej wielko�ci
prawie 50x przekraczaj�cej pojemno�� dysku. Czyli zak�adaj�c , �e Wear Leveling
dzia�a tak jak powinien, to ka�da kom�rka by�a zapisana 50x. Ale podkre�lam (i
wida� to po licznikach), �e by�o to okres bardzo intensywnego m�czenia dysku
testami (zape�nienie - trimowanie - zape�nienie - trimowania - i tak dziesi�tki
razy). Odk�d u�ywam go jako normalnego systemowego, to z tych ��cznych 2700 GB
przyby�o zaledwie 1-2 GB, a odczytu ok. 100 GB z �acznych 2900 GB.
Pozdrawiam,
latet
Kicer
>
> a na ile lat kupuszesz sprz�t?
> Bo je�li na 10-20 lat to masz racje, ale je�li na 5 to spoko SSD mo�e
> kupowaďż˝
generalnei nie lubiďż˝ sie pozbywaďż˝ dobrego sprzetu i mam 2 PC ze starymi hdd,
z olbrzymi� ilo�ci� przepracowanych godzin. Ci�gle s� jak nowe ;)
Tom01
> nie powiedzia�em �e nie, chodzi mi jedynie o to �e dost�p sekwencyjny zawsze
> jest szybszy.
Tylko uk�adach mechanicznych. Dost�p do innej kom�rki pami�ci to tylko
inny adres. Nie ma znaczenia czy jest obok czy "na drugim ko�cu" ko�ci.
--
Tomasz Jurgielewicz
Masz ochotďż˝ zapytaďż˝ mnie o monitory specjalistyczne?
Masz problem z kolorem? Wal �mia�o!
Rafał Łukawski
> W dniu 08.10.2011 12:31, Kicer pisze:
>> zawsze
>> jest szybszy.
>
> Tylko układach mechanicznych. Dostęp do innej komórki pamięci to tylko
> inny adres. Nie ma znaczenia czy jest obok czy "na drugim końcu" kości.
To nie jest prawda. Proszę zapoznać się np. z charakterystyką pamięci
DRAM. W skrócie wybranie adresu jest kosztowne, odczytywanie kolejnych
komórek (słów) znacznie mniej
Oczywiście każdy typ pamięci (np. Static RAM, ew Flash MLC/SLC itp)
należy przeanalizować niezależnie, producenci wprowadzają różnego
rodzaju usprawnienia, więc jedyną wyrocznią jest datasheet.
Tom01
> To nie jest prawda. Proszę zapoznać się np. z charakterystyką pamięci
> DRAM. W skrócie wybranie adresu jest kosztowne, odczytywanie kolejnych
> komórek (słów) znacznie mniej
>
> Oczywiście każdy typ pamięci (np. Static RAM, ew Flash MLC/SLC itp)
> należy przeanalizować niezależnie, producenci wprowadzają różnego
> rodzaju usprawnienia, więc jedyną wyrocznią jest datasheet.
Może Pan przytoczyć źródło tych danych a najlepiej i same wartości o
jakich mówimy?
--
Tomasz Jurgielewicz
Masz ochotę zapytać mnie o monitory specjalistyczne?
Masz problem z kolorem? Wal śmiało!
Rafał Łukawski
> W dniu 08.10.2011 13:53, Rafał Łukawski pisze:
>> To nie jest prawda. Proszę zapoznać się np. z charakterystyką pamięci
>> DRAM. W skrócie wybranie adresu jest kosztowne, odczytywanie kolejnych
>> komórek (słów) znacznie mniej
>>
>> Oczywiście każdy typ pamięci (np. Static RAM, ew Flash MLC/SLC itp)
>> należy przeanalizować niezależnie, producenci wprowadzają różnego
>> rodzaju usprawnienia, więc jedyną wyrocznią jest datasheet.
>
> Może Pan przytoczyć źródło tych danych a najlepiej i same wartości o
> jakich mówimy?
Dla każdej technologii jest inna specyfika, dla przykładu DDR SDRAM:
http://pl.wikipedia.org/wiki/CAS_latency
Ogólna zasada, aby zaadresować komórke - wybieramy wiersz, kolumne,
dopiero po tych operacjach (wzlględnie czasochłonnych) można
strumieniowo pobrać paczke danych
Gdy zmieniamy tylko kolumne jest to szybsze niz gdy zmieniamy wiersz i
kolumne (row, col).
Przykładowy cytat z w/w:
"Innym czynnikiem utrudniającym wyliczenie dokładnych opóźnień jest
wykorzystanie transferów ciągłych. Nowoczesny mikroprocesor może mieć
wielkość linii pamięci podręcznej wielkości 64 bajtów, wymaga to 8
transferów po 64-bity (8 bajtów) do wypełnienia linii. Za pomocą
opóźnienia CAS można wtedy dokładnie zmierzyć tylko czas przesłania
pierwszego słowa. Za czas przesłania kolejnych odpowiada opóźnienie RAS."
januszek
> http://pl.wikipedia.org/wiki/CAS_latency
> Ogólna zasada, aby zaadresować komórke - wybieramy wiersz, kolumne,
> dopiero po tych operacjach (wzlględnie czasochłonnych) można
> strumieniowo pobrać paczke danych
Tylko co to ma wspolnego z SSD? hint: nie mamy bezposredniego dostepu do
komorek fizycznej pamieci takiego dysku.
Rafał Łukawski
> Rafał Łukawski napisa?(a):
>
>> http://pl.wikipedia.org/wiki/CAS_latency
>
>> Ogólna zasada, aby zaadresować komórke - wybieramy wiersz, kolumne,
>> dopiero po tych operacjach (wzlględnie czasochłonnych) można
>> strumieniowo pobrać paczke danych
>
> Tylko co to ma wspolnego z SSD? hint: nie mamy bezposredniego dostepu do
> komorek fizycznej pamieci takiego dysku.
No w sumie racja, nie znajac dokladnych algorytmow pracy kontrolerow,
trudno dokladnie cos wnioskowac, aczkolwiek mozna przynajmniej
przypuszczac na czym polega model dzialania: - zrownowazenie ilosci
zapisow w obrebie calego dysku.
Gdyby przyjac model iz kazdy kolejny blok LBA mapowany jest na zupelnie
'losowy' blok w pamieci flash (co jest bardzo prawdopodobne po jakims
czasie dzialania), to po prostu defragmentacja z natury rzeczy nic nie
wniesie do wydajnosci, a skroci wydajnosc dysku (ze wzgledu na duza
ilosc zapisow).
Byc moze, powtarzam byc moze SSD moze stosowac algorytmy usprawniajace
odczyty kolejnych LBA /cos ala prefetch/, ale to juz tylko domysly ze
wzgledu na zlozonosc obecnych i pewno tych co powstana ukladow, wiele
jest mozliwych scenariuszy. najlepiej nie zawracac sobie tym glowy. Sama
roznica SSD vs HDD jest na tyle duza w czasie dostepu, ze po prostu sie
uzywa i tyle.
januszek
> No w sumie racja, nie znajac dokladnych algorytmow pracy kontrolerow,
> trudno dokladnie cos wnioskowac, aczkolwiek mozna przynajmniej
> przypuszczac na czym polega model dzialania: - zrownowazenie ilosci
> zapisow w obrebie calego dysku.
Dokładnie nazywa się to: Wear Leveling :)
Latet
Zastanawiam się , czy STATIC Wear Leveling robi CZASEM coś (co spowalnia) także
przy liniowym odczycie danych?
Nie wiem jak inaczej wytłumaczyć, że dwa testy HD Tune (dokładność Acurate)
zapuszczone jeden po drugim - wyglądają tak:
1. http://xyz.avx.pl/screenshots/ssd1.png
2. http://xyz.avx.pl/screenshots/ssd2.png
przy czym ten pierwszy był właczony po tygodniu bez żadnych testów, a ten drugi
zaraz po nim.
Trudno się oprzeć wrażenie, że przy pierwszym "przebiegu" dysk robił coś jeszcze
po całości....
latet
januszek
> Trudno się oprzeć wrażenie, że przy pierwszym "przebiegu" dysk robił coś jeszcze
> po całości....
moim vertexie 2 - mam wrażenie, że lepiej mu się "śmiga" ;)
Latet
> moim vertexie 2 - mam wrażenie, że lepiej mu się "śmiga" ;)
Do której wersji?
latet
MC
news:j6p5ff$8t7$1...@kushnir.sileman...
>>
> mniejsza o latanie, ale podejrzewam, �e elektronika wewn�trz umo�liwia
> szybszy odczyt/zapis jesli transfer dotyczy kolejnych blok�w (chyba we
> wszystkich urz�dzeniach od ram�w po hdd tak jest).
Tam nie ma "kolejnych blok�w".
januszek
> Do której wersji?
1.35, która wydaje się być najnowszą ;)
Latet
>
> 1.35, która wydaje się być najnowszą ;)
A którą miałeś wcześniej, tzn. między którą a którą wersją odczułeś zysk
wydajności?
latet
januszek
> A którą miałeś wcześniej, tzn. między którą a którą wersją odczułeś zysk
> wydajności?
1.2cośtam ;)
Latet
>> wydajności?
>
> 1.2cośtam ;)
Aha, bo ja mam od nowiści 1.33, więc nie wiem, czy ryzykować wgrywanie 1.35.
latet
Latet
Zaryzykowałem. Poszło gładko. Lepiej nie jest, ale na pewno nie jest gorzej.
latet
Tomasz Jasiński
doszła do mnie wiadomość <j6df84$3lu$1...@inews.gazeta.pl>
od "Latet" <la...@latet.pl> :
>> Inna metoda(już nie tak skuteczna) to wymuszenie TRIM na wolnej
>> przestrzeni dysku(jeśli na dysku masz XP czy system nie obsługujący
>> TRIM), można to zrobić z systemu obsługującego TRIM(np Win 7),
>> podłączasz taki dysk do komputera z win7, tworzysz na nim jeden wielki
>> plik z losową zawartością po czym go usuwasz.
>
>Niezbyt skuteczna metoda. Zwykle tylko pewna część miejsca "zajętego" przez
>chwilę przez ten jeden wielki plik jest faktycznie trimowana. O wiele
>skuteczniejsze jest wypełnienie całej wolnej przestrzeni dużą ilością małych
>plików i skasowanie ich. Wtedy zwykle (nie zawsze) prawa cała taka przestrzeń
>zostaje faktycznie strimowana. Przynajmniej tak się dzieje na moim OCZ Vertex 2.
>
Trimowane są wszystkie, natomiast garbage collector porządkuje tylko
kilka procent w ciągu jednej sesji(w vertexach). Tak na marginesie, do
tworzenia pliku dobrze jest użyć fsutil - plik nie będzie wypełniany
danymi - fsutil wykona tylko wpis w MFT.
>latet
>
--
Gdyby się wysadziło ich planety, zburzyło miasta,
spaliło księgi, a ich samych wytłukło do nogi,
może udałoby się ocalić naukę miłości bliźniego. SL.
Mirek
Rafaďż˝ wrote:
>
>
> qwerty wrote:
>
>> U�ytkownik "Rafa�" napisa� w wiadomo�ci grup
>> dyskusyjnych:4E8DBFD5...@gazeta.pl...
>> > umiesz czytaďż˝ ze zrozumieniem?
>> > To przeczytaj jeszcze raz moj� wypowied� szczeg�lnie
>> > o tych zarezerwowanych 5%
>> > Tak na spokojnie :)
>>
>> Jako� nie chce mi si� wierzy� w te 5% Raczej 2-3 %. Nawet przyjmuj�c 5% to przy
>> dysku 60 GB daje nam ok 160 dni.
>
> 5% zarezerwowane jest np. przy dysku A-Data S511.
http://www.myce.com/review/ocz-vertex-2-100gb-ssd-review-30021/SandForce-SF1200-SSD-controller-2/
28%
> Tak wiec dopiero po p� roku mo�esz ujrze� widoczny efekt
> swojej 'pracy' czyli uszkodzenia dysku. Mo�esz, ale nie musisz,
> bo producenci deklaruj� i� po tym milionie zapis�w dysk
> b�dzie jeszcze ca�kiem sprawny. Zreszt� niekt�rzy producenci
> gwarantujďż˝ 2 mln cykli.
Kt�ry producent ko�ci MLC tyle daje?
> Nie wiem jak wyliczy�e� to 160 dni,
Dla w/w warunk�w i typowej �ywotno�ci MLC nie przekraczaj�ce raczej 10k
cykli: http://www.anandtech.com/show/4159/ocz-vertex-3-pro-preview-the-first-sf2500-ssd/2
nawet przy static wear levelling mi wychodzi: 10000/2*60/(.5/2)/(3600*24) < 14 dni
:()