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

do góry

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

do góry

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

do góry

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

do góry

qwerty wrote:

> Użytkownik "januszek" napisał w wiadomości grup
> dyskusyjnych:s...@g...mierzwia
k.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.

do góry

> 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

do góry

> 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

do góry

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.

do góry

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

do góry

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.

do góry