Polećcie jakiś SSD pod system

[latet]

Napisany przez Matefusz

Mam pytanie: jak dbać o dysk SSD? Wiem, że nie można go defragmentować. Czy funkcja TRIM jest domyślnie włączona czy trzeba ją włączyć?

Odpowiem jakby od końca

Ściągnij program SSDLife - pokazuje info o stanie i żywotności dysku, jego statystyki (transfery) oraz czy włączony jest TRIM:


Zerkaj też w SMART - polecam do tego Crystal Disk Info, bo "rozumie" i opisuje ludzkim językiem specyficzne dla SSD wartości SMART:


Defragmentacja jest demonizowana - ale oczywiście nie należy jej robić, głównie dlatego, że nie ma to sensu.

Polecam też SSD Tweaker, proste narzędzie (wystarczy wersja darmowa), które pomaga wygodnie zmienić kilka systemowych ustawień, pod kątem SSD. Na screenie widać, jak to ustawiłem u siebie (pod XP) - moim zdaniem optymalnie.


Jest też kwestia pliku wymiany oraz folderów tymczasowych. Moim zdaniem plik wymiany jak najbardziej powinien być na SSD, przy czym dobrze, aby jego wielkość była jak najmniejsza (a to zależy od osobistych potrzeb i od ilości RAM-u). Spróbuj od 256MB, w razie czego powiększaj. Pod Win7 nie powinno być takiej potrzeby.

Z kolei foldery tymczasowe - zwłaszcza foldery cache przeglądarek www - warto trzymać w RAM-disku. Polecam prosty w obsłudze, darmowy DataRam Ramdisk. Pod Win7 można nawet na takim ramdisku trzymać plik wymiany. Jakby mi się nie chciało używać RAM-Disku, to trzymałbym foldery tymczasowe na SSD (bo nie po to kupuję SSD, aby nie korzystać z uroków jego wydajności).

[Matefusz]

Plik wymiany wyłączyłem w ogóle. Mam 8GB ramu.

[latet]

Napisany przez Matefusz

Plik wymiany wyłączyłem w ogóle. Mam 8GB ramu.

Jeśli nie daje to żadnych efektów ubocznych, to super.

Napisany przez Matefusz

Jeszcze wypadałoby zaszyfrować dysk TrueCryptem. Ale po analizie poprzednich postów chyba się wstrzymam... (słaba wydajność)

Zachęcam jednak do testu. Samo zaszyfrowanie trwa z 10 minut i jest łatwo odwracalne (też z 10 minut), co przywraca wydajność. Co Ci szkodzi sprawdzić? Nie ukrywam, że bardzo mnie ciekawi, jak zmieni się wydajność Samsunga po zaszyfrowaniu - wszak jego chipset nie opiera swej wydajności na kompresji danych (jak mój Vertex2). Spadek wydajności może być więc nieznaczny.

Tylko jednak stanowczo polecam zostawić trochę miejsca niezaszyfrowanego (drugą, niewielką, pustą partycję). Najpierw zaszyfrowałem cały dysk - spadek wydajności był znaczy. Potem się z tego wycofałem - i zaszyfrowałem jeszcze raz, ale z pozostawieniem małej, niezaszyfrowanej partycji. Spadek wydajności jest bez porównania mniejszy!

Niżej twarde konkrety z Crystal Disk Mark(niebieskie = bez szyfrowanie, czerwone = cały dysk zaszyfrowany, zielone = prawie cały dysk zaszyfrowany).

Zapis sekwencyjny: 68 MB/s - 13 MB/s - 66 MB/s

4K zapis: 54 MB/s - 12 MB/s - 40 MB/s

4K-64Thr zapis: 62 MB/s - 9 MB/s - 39 MB/s

Marzy mi się zobaczyć taki komplet danych dla Samsunga, ale zadowolę się tylko niebieskim + jednym z dwóch pozostałych

[Misiek4]

Latet, prosze bardzo: http://forum.cdrinfo.pl/f102/samsung...0/#post1199190

[Matefusz]

Napisany przez Misiek4

Latet, prosze bardzo: http://forum.cdrinfo.pl/f102/samsung...0/#post1199190

A jak z TIMRem? @Sorbus pisał, że może być problem z zachowaniem dobrej kondycji dysku gdy jest cały zaszyfrowany TC... Też chcę zaszyfrować ale boje się, że skróci się żywotność.

[latet]

Napisany przez Matefusz

A jak z TIMRem? @Sorbus pisał, że może być problem z zachowaniem dobrej kondycji dysku gdy jest cały zaszyfrowany TC... Też chcę zaszyfrować ale boje się, że skróci się żywotność.

Jak z TRIM-em to dokładnie nie wiem (sprzeczne dane), natomiast na pewno pozostawienie części dysku niezaszyfrowanego korzystnie wypłynie i na żywotność i na wydajność.

Zaszyfrowałeś cały dysk - aby odczuć prawdziwy spadek wydajności musisz go trochę poużywać (dużo pozapisywać), bo przy pierwszych testach wykorzystywany jest niewidoczny dla użytkownika margines wolnych sektorów. Z każdym testem wynik powinien być gorszy, aż do ustalenia się na na jakimś tam (złym) poziomie. Potem tylko małe wahania. Przynajmniej tak się zachowuje Vertex2, ale co dysk to obyczaj - możliwe, że Samsung ma inne algorytmy i inaczej to wszystko wygląda.

Co do żywotności to spokojnie. Monitoruj dysk i jeśli zauważysz, że starzeje się szybciej, niż być chciał (tzn. początkowo prognozowana data "śmierci" zmienia się na niekorzyść) to zawsze przecież możesz go odszyfrować. Ale mogę się założyć, że zanim do tego dojdzie, minie parę lat i i tak będziesz myślał o nowym, większym, szybszym, lepszym...

[sobrus]

Wydaje mi się że szyfrowanie nie skraca żywotności dysku, jedynie uniemożliwia wear levelling. Nie wiem też jak zachowa się w przypadku systemów COW takich jak BTRFS (one nie nadpisują poprzednich danych).
Po prostu co i gdzie TC zapisuje jest jedną wielką niewiadomą, bo wszystko jest szyfrowane. Pozostawienie pewnej niezaszyfrowanej części umożliwia wear levelling - system podmienia najbardziej zużyte sektory na sektory z tego obszaru.
Ale to tylko moje teorie.
A co do zwiększania żywotności to zredukuj liczbę zapisów. Na początek wyłącz aktualizację daty ostatniego dostępu do pliku/katalogu, bo przez to każdy odczyt pliku to jednocześnie zapis i SSD dostaje po tyłku. Wyłączenie generowania nazw 8.3 też powinno pomóc.

[latet]

Napisany przez sobrus

Wydaje mi się że szyfrowanie nie skraca żywotności dysku, jedynie uniemożliwia wear levelling. Nie wiem też jak zachowa się w przypadku systemów COW takich jak BTRFS (one nie nadpisują poprzednich danych). Po prostu co i gdzie TC zapisuje jest jedną wielką niewiadomą, bo wszystko jest szyfrowane. Pozostawienie pewnej niezaszyfrowanej części umożliwia wear levelling - system podmienia najbardziej zużyte sektory na sektory z tego obszaru.Ale to tylko moje teorie.

Z którymi znów się zgodzić nie mogę :-)
Szyfrowanie nie uniemożliwia wear levellingu. Kontroler SSD doskonale wie ile razy dany "sektor" był zapisywany, niezależnie od tego, czy jego zawartość jest zaszyfrowana, czy nie. Kontroler SSD nawet nie wie, że dane tam zawartą były szyfrowane. Nie jest żadną niewiadomą gdzie TC zapisuje dane. Robi to normalnie, wg adresów LBA (szyfrowanie jest na poziomie poszczególnych klastrów lub sektorów, a nie plików). Natomiast zawsze zagadką jest gdzie naprawdę kontroler SSD dany pakiet danych sobie fizycznie zapisze, ale ważne jest to, że będą one dostępne pod tym samym logicznym adresem LBA, pod którym zostały zapisane.

[sobrus]

Owszem, kontroler doskonale wie, które sektory były najczęściej używane.
Tyle że przy zaszyfrowanym dysku nie ma żadnego pola manewru z wyborem "najmniej zużytego" sektora, bo wolnych nie ma.
Wolny sektor zaszyfrowany niczym się nie różni w swojej fizycznej reprezentacji od zajętego. Bo przecież nawet informacja że jest pusty jest tajna.

Ponieważ to były tylko moje teorie zapytałem google:

Worse: this is also of concern with regard to durability of (fully) encrypted SSDs. As wear leveling mechanisms can not make use of any blocks in partitions being encrypted with TrueCrypt, the SSD controller could only use some reserved overhead space (some reserved blocks dedicated to wear leveling) which will be heavily used and therefore become corrupt quite early. To prevent that, you should leave some unpartitioned space on your SSD if you plan to fully encrypt it as the controller can use this space for wear leveling.

Czyli mam racje
http://media-addicted.de/ssd-and-tru...ce-issues/744/


Najprościej traktorać zaszyfrowaną partycję jako taką, która jest po brzegi wypełniona jednym wielkim plikiem.
Fizycznie wszystkie operacje, które uzytkownik wykonuje na dysku to nadpisywanie fragmentów tego pliku (dokładnie tak w obrazach HDD w virtualboxie).
Wolne miejsce istnieje logicznie wewnątrz tego pliku, ale fizycznie plik zawsze zajmuje cały dysk i kontroler nic nie wykombinuje, bo zajrzeć do środka nie może .

Moim zdaniem szyfrowanie całego SSD jest złe, ponieważ stoi w sprzeczności z mechanizmami działania tych dysków. Nie dość że bardzo je spowalnia, to jeszcze skraca żywotność (wear levelling ma do dyspozycji jedynie wydzielone pare GB miejsca, podczas gdy normalnie jest to prawie cały dysk).
Czyli taki dysk padnie wielokrotnie szybciej, tym szybciej im mniej miejsca wolnego zostawimy, a miejsce na SSD jest drogie i szkoda je marnować.

W normalnych warunkach, dysk jest tym mniej zapisywany, im mniej miejsca wolnego na nim zostało. Gdy miejsca juz nie ma, zapis staje się niemożliwy, a tym samym WL staje sie zbędny.
W przypadku TC dysk jest cały zagrany przy jednoczesnym bardzo częstym nadpisywaniu zawartości. I jest kicha.

Rozwiązaniem jest szyfrowanie na poziomie systemu plików (NTFS ma taką możliwość) lub niewielkiej partycji (powiedzmy 10-20% pojemności dysku), którą wear levelling będzie mógł fizycznie przenosić w obrębie niezaszyfrowanego wolnego miejsca.

Tak czy inaczej prędkości dysków będą spadać, bo wear levelling prowadzi do bardzo dużej fragmentacji danych całkowicie niewidocznej dla użytkownika i systemu plików.
Nie jest to moze bardzo zauważalne przy operowaniu małymi plikami, ale przy duzych, takich jak zaszyfrowane partycje, to na pewno ma spore znaczenie. Po jakimś czasie taka partycja, nawet stosunkowo mała, będzie rozsiana po całym dysku (zapisana na najmniej zużytych sektorach). I nie da się tego zdefragmentować i nic nie pomoże tu nawet najwymyślniejszy system plików . Czas dostępu tych dysków jest mały, ale nie jest chyba absolutnie zerowy - więc prędkość spada.

edit. Wyłącz 8.3 name creation, to zbędne operacje zapisu na dysku.
edit2: ale sie rozpisałem

[Misiek4]

O ile to ma jakiekolwiek znaczenie: 830'ka zaszyfrowana w pelni i dwukrotnie zapelniona danymi: klik. Jak ktos ma jakies pomysly na dodatkowe testy, to smialo prosze, bo niedlugo na tym SSD pojawi sie system.

[sobrus]

Myśle że na tak świezym dysku różnic na razie nie będzie. A nawet może w ogóle prędkość nie będzie spadać, po prostu dysk szybciej padnie niż niezaszyfrowany.
Ale to prędko to nie nastąpi, trzebaby na dysku TC założyć SWAPa i z niego intenstywnie korzystac).

Bardzo ładne wyniki biorąc pod uwagę że zaszyfrowane dane jest dla kontrolera zupełnie niekompresowalne i kompresja SandForce (ani żadna inna) po prostu z TC nie działa.
(to kolejny argument że nie ma co kompresowac SSD).

[Arepo]

Mój roczny dysk ma 78% health , ale rokują mu życie do 2020, ciekawe

[latet]

Napisany przez Arepo

Mój roczny dysk ma 78% health , ale rokują mu życie do 2020, ciekawe

A możesz pokazać SMART (widziany przez świeżą wersję Crystal Disk Info)?

[Arepo]

Tak to wygląda :

[latet]

Witam,

Zrobiłem taki wielodniowy eksperyment, myślę, że rezultat jest ciekawy:



Zielone słupki - przed zaszyfrowaniem.

Używam programu DataRam Ramdisk, który za każdym razem przy zamykaniu systemu zapisuje na dysk (SSD) dokładnie 1 GB danych - stąd te czasy są tak duże.

Wyraźnie widać, jak korzystnie na wydajność wpływa pozostawienie paru GB niezaszyfrowanych.
Zwróćcie uwagę - dodatkowe miejsce (to niewidoczne dla użytkownika i systemu) wystarczyło na całkiem zaszyfrowanym dysku na w miarę szybko zapis tylko dwa razy. Potem czasy zapisu gwałtownie poszły w górę.

Od zakończenia zbierania danych do tych wykresów minęło 5-6 dni, czasy zamykania nadal na tym samym poziomie. A przecież niezaszyfrowanej przestrzeni zostawiłem tylko 5 GB. Została więc już kilka razy zapisana zaszyfrowanymi danymi. Wniosek? Garbage collection radzi sobie z zaszyfrowanym dyskiem!. Czyli potrafi oznaczać zaszyfrowane sektory jako wolne i je zerować (co jest podobne do TRIM).

Ale nawet przy całym dysku zaszyfrowanym mechanizm ten jakoś tam działa (stąd skoki czasów - w dół), ale jest bardzo mało wydajny.

Polecam też uwadze to: http://www.truecrypt.org/docs/?s=trim-operation
jest tam wprost napisane, że pod Windows TRIM działa na dyskach zaszyfrownych TrueCryptem.

Some storage devices (e.g., some solid-state drives, including USB flash drives) use so-called 'trim' operation to mark drive sectors as free e.g. when a file is deleted. Consequently, such sectors may contain unencrypted zeroes or other undefined data (unencrypted) even if they are located within a part of the drive that is encrypted by TrueCrypt. TrueCrypt does not block the trim operation...

(z tego co tam dalej piszą można wnioskować, że pod Linuxem TRIM jest jednak blokowany).

Pozdrawiam.