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?

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

On 2011-10-01 22:57, Latet wrote:

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/

W dniu 2011-10-01 22:57, Latet pisze:

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?

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

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.

Użytkownik "Jerzy Dombczak"  napisał w wiadomości

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.

Użytkownik "Latet" <latet@latet.pl> napisał

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...

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

W dniu 2011-10-01 22:57, Latet pisze:

Witam,

Wiem, że dysków SSD nie powinno się defragmentować, bo po pierwsze

Wiesz, a dalej gdybasz. Pamięć ram też sobie defragmentujesz ?

Dnia 03.10.2011 Piotr "Charvel" Majka <charvel@localhost.link.pl> napisał/a:

W dniu 2011-10-01 22:57, Latet pisze:

Witam,

Wiem, że dysków SSD nie powinno się defragmentować, bo po pierwsze

Wiesz, a dalej gdybasz. Pamięć ram też sobie defragmentujesz ?

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.

Sergiusz Rozanski napisa?(a):

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ść.

To nie prawda bo fragmentacja plikow w SSD nie ma zadnego znaczenia dla 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!"

W dniu 03.10.2011 20:36, Sergiusz Rozanski pisze:

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.

Trzeba być niezłym debilem, żeby taki dysk formatować z podziałem na 512-bajtowe klastry.

Trzeba być niezłym debilem, żeby taki dysk formatować z podziałem na 512-bajtowe klastry.

A warto zastosowac inne, niż standardowe 4 KB?
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

Użytkownik "Latet" <latet@latet.pl> napisał w wiadomości news:j6dfel$3uh$1inews.gazeta.pl...

Trzeba być niezłym debilem, żeby taki dysk formatować z podziałem na 512-bajtowe klastry.

A warto zastosowac inne, niż standardowe 4 KB?
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.

Na dysku SSD? Partycje ani żadne inne dane w rodzaju wielkości klastrów nie mają nic wspólnego z rzeczywistością. Kontroler SSD sam rządzi tym wszyskim.

Na dysku SSD? Partycje ani żadne inne dane w rodzaju wielkości klastrów nie mają nic wspólnego z rzeczywistością. Kontroler SSD sam rządzi tym wszyskim.

Może wielkość klastrów nie ma znaczenia, ale partition alignment ma - ogromne. Sprawdziłem.

latet

Użytkownik "Latet" <latet@latet.pl> napisał w wiadomości news:j6h8vr$24d$1inews.gazeta.pl...

Na dysku SSD? Partycje ani żadne inne dane w rodzaju wielkości klastrów nie mają nic wspólnego z rzeczywistością. Kontroler SSD sam rządzi tym wszyskim.

Może wielkość klastrów nie ma znaczenia, ale partition alignment ma - ogromne. Sprawdziłem.

To jakiś przypadkowy wynik, jak w wielu twoich sprawdzianach. Taki związek jest po prostu z definicji niemożliwy.

Może wielkość klastrów nie ma znaczenia, ale partition alignment ma - 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.

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

Użytkownik "Latet" <latet@latet.pl> napisał w wiadomości news:j6i47s$5gu$1inews.gazeta.pl...

Może wielkość klastrów nie ma znaczenia, ale partition alignment ma - 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.

Taak? A co to jest LBA w wypadku SSD?

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).



--
Western Digital Silver Partner - http://luktronik.pl/

Użytkownik "Rafał Łukawski" <rafalweb@lukawski.pl> napisał w wiadomości news:j6kbn0$d7j$1news.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).

Tyle, ze ta mapa nie jest stała, więc LBA ileś tam nie oznacza za kazdym razem tej samej komórki pamięci. A więc testy kolegi są bez sensu.

Tyle, ze ta mapa nie jest stała, więc LBA ileś tam nie oznacza za kazdym 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/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

Użytkownik "Latet" <latet@latet.pl> napisał w wiadomości news:j6kslt$sme$1inews.gazeta.pl...

Tyle, ze ta mapa nie jest stała, więc LBA ileś tam nie oznacza za kazdym 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://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.

Szkoda, że nie rozumiesz znaczenia słowa forum. Nie mówiąc już o treści samych wiadomości.

Dobrze, nie czytajmy for. Po prostu weź jakiś dysk SSD, załóz partycję od LBA63, 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.

Latet wrote:

* - 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

103424 K - OK

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

Użytkownik "Latet"  napisał w wiadomości grup dyskusyjnych:j6dfel$3uh$1@inews.gazeta.pl...

A warto zastosowac inne, niż standardowe 4 KB?
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.

A warto zastosowac inne, niż standardowe 4 KB?
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.

Na SSD, ale nie testowałem czasu startu systemu pod kątem wielkości klastrów.
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

Użytkownik "Sergiusz Rozanski" <write-only-with-spf@media-lab.com.pl> napisał w wiadomości news:slrnj8k05a.d9m.write-only-with-spfdns.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.

Proszę nie zmyślać.

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.

Odczyt w dyskach SSD nie jest specjalnym problemem. Skąd tylu mądrali postanowiło rozwiązać nieistniejący problem?

Wcale nie przypadkiem, dnia Sat, 1 Oct 2011 22:57:02 +0200  doszła do mnie wiadomość  <j67ur2$ag7$1@inews.gazeta.pl>  od "Latet" <latet@latet.pl>  :

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?

Defragmentacja nic nie da, może tylko powiększyć wewnętrzny bałagan na
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ę). Pewnie ten program wykonuje jakiś szczególny rodzaj odczytu sektorów z pomiarem 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

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.

latet

Użytkownik "Latet"  napisał w wiadomości grup dyskusyjnych:j6df84$3lu$1@inews.gazeta.pl...

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.

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 napisa?(a):

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.

Dlaczego zdycha?

j.


--
http://www.predkosczabija.pl/
"Prędkość zabija. Włącz myślenie!"

UĹźytkownik "januszek"  napisał w wiadomości grup dyskusyjnych:slrnj8osjf.2175.januszek@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.

qwerty napisa?(a):

Ile komórki dają radę się zapisać? 1 mln? Załóżmy, że jest nadpisywany co 2 sekundy. W 23 dni uśmiercasz dysk.

Hmm... Czy Ty aby na pewno rozumiesz jak działają dyski SSD? Nie masz 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.

j.

--
http://www.predkosczabija.pl/
"Prędkość zabija. Włącz myślenie!"

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.

To, co widać na tych wykresach pokazuje różną prędkość odczytu dla obszarów zapisanych danymi oraz strimowanych. Różnica charakterystyczna dla chipsetów Sandforce - które wykorzystują kompresję danych w locie do przyśpieszenia transferów.

latet

qwerty wrote:

UĹźytkownik "januszek"  napisał w wiadomości grup
dyskusyjnych:slrnj8osjf.2175.januszek@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.

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ć?

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

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ć?

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
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.

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.
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.


latet

Latet wrote:

>> 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.

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)

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.

Ja nie zauważyłem radykalnej zmiany, dlatego tempy mam na innym dysku.
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.

Użytkownik "Rafał" <bezspamuXXX@gazeta.pl> napisał

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)

Ale wlasnie probowano Ci wytlumaczyc, ze takie "oszczedzanie" dysku jest bez 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

Użytkownik "Rafał"  napisał w wiadomości grup dyskusyjnych:4E8CB053.F9CCFC88@gazeta.pl...

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?

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?

qwerty napisa?(a):

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?

Bo kontroler i tak bedzie ruszal te dane (z 99,9% reszty komorek), czy Czy sie to podoba czy nie. Musisz zupdateowac swoj dogmat ;P

j.

--
http://www.predkosczabija.pl/
"Prędkość zabija. Włącz myślenie!"

qwerty wrote:

Użytkownik "Rafał"  napisał w wiadomości grup
dyskusyjnych:4E8CB053.F9CCFC88@gazeta.pl...
> 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?

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?

umiesz czytać ze zrozumieniem?
To przeczytaj jeszcze raz moją wypowiedź szczególnie
o tych zarezerwowanych 5%
Tak na spokojnie :)

Użytkownik "Rafał"  napisał w wiadomości grup dyskusyjnych:4E8DBFD5.7F6E48A3@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.

qwerty wrote:

Użytkownik "Rafał"  napisał w wiadomości grup
dyskusyjnych:4E8DBFD5.7F6E48A3@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.
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

On czw, 06 paź 2011 17:29:03 in article news:<4E8DC93F.60C5A340@gazeta.pl>
Rafał wrote:

qwerty wrote:

Użytkownik "Rafał"  napisał w wiadomości grup
dyskusyjnych:4E8DBFD5.7F6E48A3@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

:()

Wcale nie przypadkiem, dnia Thu, 6 Oct 2011 17:01:40 +0200  doszła do mnie wiadomość  <j6kfsh$hjr$1@inews.gazeta.pl>  od "qwerty" <qwerty01@poczta.fm>  :

Użytkownik "Rafał"  napisał w wiadomości grup dyskusyjnych:4E8DBFD5.7F6E48A3@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.

Static wear leveling:
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.

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.

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.

Ale co to ma wspólnego z metodami skutecznego trim-owania?

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

Wcale nie przypadkiem, dnia Tue, 4 Oct 2011 01:07:46 +0200  doszła do mnie wiadomość  <j6df84$3lu$1@inews.gazeta.pl>  od "Latet" <latet@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.

W dniu 01.10.2011 22:57, Latet pisze:

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.

Nie tyle nie jest uciążliwa, ile nie istnieje - poza czysto umowną 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...

Myślisz, że po tych komórkach pamięci jakaś głowica lata? ;->

Andrzej Lawa wrote:

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

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.

--
Tomasz Jurgielewicz
Masz ochotę zapytać mnie o monitory specjalistyczne?
Masz problem z kolorem? Wal śmiało!
monitory.mastiff.pl, gg: 189335, skype: zpkmastif

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ą.

pozdrawiam

--
Michał Walenciak
gmail.com kicer86
http://kicer.sileman.net.pl
gg: 3729519

Kicer wrote:

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ć

Rafał wrote:

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 ;)

pozdrawiam

--
Michał Walenciak
gmail.com kicer86
http://kicer.sileman.net.pl
gg: 3729519

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ą.

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

W dniu 08.10.2011 12:31, Kicer pisze:

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!
monitory.mastiff.pl, gg: 189335, skype: zpkmastif

On 2011-10-08 13:48, Tom01 wrote:

W dniu 08.10.2011 12:31, Kicer pisze:

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.

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.

--
Western Digital Silver Partner - http://luktronik.pl/

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?

--
Tomasz Jurgielewicz
Masz ochotę zapytać mnie o monitory specjalistyczne?
Masz problem z kolorem? Wal śmiało!
monitory.mastiff.pl, gg: 189335, skype: zpkmastif

On 2011-10-08 16:00, Tom01 wrote:

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."

--
Western Digital Silver Partner - http://luktronik.pl/

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.

j.


--
http://www.predkosczabija.pl/
"Prędkość zabija. Włącz myślenie!"

On 2011-10-08 17:09, januszek wrote:

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.



--
Western Digital Silver Partner - http://luktronik.pl/

Rafał Łukawski napisa?(a):

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 :)

j.

--
http://www.predkosczabija.pl/
"Prędkość zabija. Włącz myślenie!"

Dokładnie nazywa się to: Wear Leveling :)

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

Latet napisa?(a):

Trudno się oprzeć wrażenie, że przy pierwszym "przebiegu" dysk robił coś jeszcze po całości....

Kontroler cały czas coś tam robi ;) Nawiasem mówiąc po ugrade firmware w moim vertexie 2 - mam wrażenie, że lepiej mu się "śmiga" ;) j.

--
http://www.predkosczabija.pl/
"Prędkość zabija. Włącz myślenie!"

Kontroler cały czas coś tam robi ;) Nawiasem mówiąc po ugrade firmware w
moim vertexie 2 - mam wrażenie, że lepiej mu się "śmiga" ;)

Do ktĂłrej wersji?

latet

Latet napisa?(a):

Do ktĂłrej wersji?

1.35, która wydaje się być najnowszą ;)

j.


--
http://www.predkosczabija.pl/
"Prędkość zabija. Włącz myślenie!"

Do ktĂłrej wersji?

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

Latet napisa?(a):

A którą miałeś wcześniej, tzn. między którą a którą wersją odczułeś zysk wydajności?

1.2cośtam ;)

j.

--
http://www.predkosczabija.pl/
"Prędkość zabija. Włącz myślenie!"

A którą miałeś wcześniej, tzn. między którą a którą wersją odczułeś zysk
wydajności?

1.2cośtam ;)

Aha, bo ja mam od nowiści 1.33, więc nie wiem, czy ryzykować wgrywanie 1.35.

latet

Aha, bo ja mam od nowiści 1.33, więc nie wiem, czy ryzykować wgrywanie 1.35.

Zaryzykowałem. Poszło gładko. Lepiej nie jest, ale na pewno nie jest gorzej.

latet

Użytkownik "Kicer" <a@b.c> napisał w wiadomości news:j6p5ff$8t7$1kushnir.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".