No to różnimy się zdaniem :taktak:

Myślę, że źle myślisz. Nie tak działa szyfrowanie partycji. Żadne komórki nie są "zajęte" przez TrueCrypta. TrueCrypt działa na niższym niż system plików poziomie - na poziomie sektorów. Na zwykłym HDD jest to proste: system prosi o sektor LBA nr X, dysk wysyła jego zawartość, a po drodze TC go rozkodowuje. I na odwrót. To, że puste miejsce zostało zaszyfrowane w procesie tworzenia zaszyfrowanej partycji, nie oznacza, że jest ono w jakikolwiek sposób "zajęte" / "trzymane" / "zarezerwowane" przez TC. To nadal jest wolne miejsce i jeśli system chce tam coś zapisać, to zapisuje (po zaszyfrowaniu w locie) - bez zwracania uwagi na to, co tam właśnie sobie leżało. Jeśli system kasuje plik, to nie obchodzi go, czy był zaszyfrowany, czy nie - dla systemu jest to wolne miejsce i może o tym poinformować sprzęt komendą TRIM.

Wiem, ale pomyśl, jak kontroler SSD może wyzerować jakąkolwiek komórkę pamięci jeżeli każda jest zajęta przez truecrypta?
TC nie może zwolnić sektora, bo nawet jeżeli jest wolny, to jest to zaszyfrowane i fizycznie coś jest ;)
Wynika z tego, że na zaszyfrowanym dysku nie ma czegoś takiego jak wolne miejsce fizycznie na dysku.
Wolne jest tylko logicznie wewnątrz zaszyfrowanego wolumenu.

A w przykładzie chodziło o to, żeby zobaczyć, że dane na zaszyfrowanym dysku mają się nijak do danych fizycznie zapisanych na medium, czy to plik czy fizyczny dysk.

Przykładowo mamy dane i ich reprezentacje na dysku (dane wyżej, zapis poniżej):
Zdanie zajmuje cały dysk, a literki to są pliki (spacja też). 0 to wyczyszczona przez kontroler komórka na dysku.

Normalny dysk:
Kasujemy drugie zdanie i robimy TRIM

A teraz to samo zaszyfrowane

Kasujemy drugie zdanie i robimy TRIM

Jak widać dane zostały skasowane, ale dysk tego nie zobaczył. Łańcuch sie zmienił, ale jego długość pozostała taka sama i nie ma gdzie zrobić TRIMA.
Wolumen skompresowany to wlasnie taki łańcuch zajmujący całą powierzchnię dysku.

Jeżeli oczywiście TC działa tak jak myślę :taktak:

Takie zerowanie nie ma nic wspólnego z zerowanie przez kontroler SSD. Pomieszałeś kompletnie różne rzeczy :)

Jeżeli wear levelling potrafi zmieniać istniejące dane miejscami, to jest to dla mnie ciut bezsensowne. Po pierwsze przeniesienie sektora to dodatkowa operacja zapisu, a po drugie zostawianie kawałka niezaszyfrowanego dysku dla WL byłoby bezcelowe. Z tego co wiem (ale moze sie myle) WL wybiera przy zapisie tylko spośród sektorów niezapisanych. W dysku zaszyfrowanym wszystkie są jednak zapisane.

Co do TRIM to, znowu moge się mylić, ale chyba chodzi o to, że nadpisanie komórki pamięci jest znacznie wolniejsze, niż zapis do czystej.
Dlatego po usunięciu pliku należy ją wyczyścić, zeby prędkość dla następnego pliku sie nie zmniejszyła.
Dysk jednak nie wie, które sektory są wolne, dopóki system plików mu tego nie powie.

ALE

Zaszyfrowanego dysku nie można poddać wyzerowaniu, bo w nim nie ma pustych sektorów. Zrób mały test.
Załóż zaszyfrowany plik TrueCrypt dowolnej wielkości, sformatuj go a następnie wyzeruj przy pomocy np CCleaner. Cały dokładnie wyzeruj.
I zobacz co będzie widoczne w pliku TC z zewnątrz. Nie zera, ale piękne "losowe" bzdury, bo puste miejsce też jest zaszyfrowane.
I to wlasnie widzi (prawdopodobnie) dysk. Choć to są nic nie warte bzdury, takich komórek nie można po prostu skasować - i trim nie działa.

Gdyby Trim działał, możnaby po analizie powierzchni np powiedzieć, ze na dysku jest 100MB danych, bo reszta komórek jest skasowana.
A to juz jest pewna informacja o zawartości, tymczasem każdy dysk TrueCrypta wyglada zawsze na losowe bzdury, aby nie dało się nawet udowodnić, że to jakieś zaszyfrowane dane.
Wg wikipedii każdy dysk TC przechodzi pomyślnie test chi kwadrat na losowość, można zaprzeczyć w razie czego przed np policją. że tam w ogóle są jakieś dane.

Dla WR liczy się też częstość używania danego sektora. Dlatego m.in. zamienia dane (nawet i zaszyfrowane) miejscami.

Nie, to zupełnie nie tak. Polecam: http://en.wikipedia.org/wiki/Write_amplification
Cytat:
Jeśli plik zajmujący pewien obszar jest kasowany, to kontroler otrzymuje jego "namiary" i wie, że można go poddać wyzerowaniu (szybkiemu - bez przenoszenia zawartości w inne miejsce), przy najbliższej okazji (przy garbage collection). Nie ma więc znaczenia jakie tam są dane, czy zaszyfrowane, czy nie. Ważne, że zostały uznane za niepotrzebne. A przecież TrueCrypt przy normalnym kasowaniu plików nie robi żądnego ich napisania (bo i po co). Tak to jest w teorii. W praktyce - trim nie działa, nie wiem czemu, ale w sumie wychodzi na Twoje ;)

Ale jest też coś takiego jak nadpisywanie plików - w SDD działa to w szczególny sposób (znów polecam: http://en.wikipedia.org/wiki/Write_amplification) - dzięki temu część sektorów i tak powinna być zerowana (w ramach GC, nawet pod systemem bez obłsugi TRIM - np. XP). Przez ostatnie pół roku jechałem na SSD pod XP, bez żadnego TRIM i wydajność dysku cały czas utrzymywała się na tym samym, dobrym poziomie (co badałem regularnie).

P.S. Problem długiego otwierania się folderów - póki co mnie nie dotknął.

Wiem do czego służy wear levelling, ale system nie może wybrać do zapisu sektora najmniej używanego, ponieważ w skompresowanym dysku wszystkie są zawsze używane.

Podobnie nie wiem jak moze działać TRIM, skoro dane zaszyfrowane wyglądają jak losowe. Nawet puste sektory są zapełnione losowymi danymi, aby uniemożliwić jakąkolwiek analizę statystyczną itp.
Więc TRIM nie może działać, bo jego zadaniem jest fizyczne skasowanie, wyzerowanie pustego sektora, co jest sprzeczne z szyfrowaniem.

Co do reszty to niestety - przykro czytać. Przecież nie po to sie kupuje dysk SSD, żeby bawić się ram dyskiem! Jak czytam o katalogach wczytujących się 5 sekund to przechodzą mi ciarki po plecach.

Na moje szczęscie opisane problemy nie występują prawdopodobnie w linukse.
EXT4 automatycznie non-stop zajmuje sie TRIMem przez co nie występuje degradacja szybkości z czasem, a sam linux bardzo rzadko korzysta z dysku (a tym bardziej ze swapa, którego można w ogóle nie mieć).
Do tego mamy ramdyski, kompresowane ramdyski, kompresowane swapy w pamieci (z moich obserwacji typowo kompresja 5:1, czas dostępu 0.0, transfer 12GB/s).
Oraz cache dyskowe które można ustawić jak sie chce.

Także przy wszystkich wadach linuksa (a jest ich duzo) - dla lubiących szybkość jest się czym bawić :taktak:.

Wear leveling (sam w sobie) nie służy przyśpieszaniu, ale wydłużaniu życia dysku. Sam się zdziwiłem - http://en.wikipedia.org/wiki/Write_amplification - ale zerknij na tabelkę "Factors affecting the value".

Ale co do TRIM - wiem, że nie działa - sprawdziłem, ale nie rozumiem dlaczego. Powinien działać, co potwierdza manual TC:

Ciekawe, czy zacznie mi się teraz zwiększać licznik zużycia dysku - do tej pory od pół roku (od nowości) cały czas pokazywał tę samą prognozę: życie do grudnia 2019. Na razie nadal tak pokazuje, ale pewnie to się zacznie zmieniać.

Pocieszam się jednak, że używam tego dysku praktycznie na tyle read-only na ile to możliwe. Jest na nim system, ale co tylko się dało - przeniosłem do RAMdisku, a duże i często zapisywane rzeczy (np Moje Dokumenty) na dyski magnetyczne. Na c: zostało tylko co co musiało (lub nie wiedziałem jak przenieść). Jak pisałem na wstępie - mimo tragicznej różnicy w testach, nie odczułem różnicy w szybkości ładowania systemu i programów. Wydłużył się tylko czas zamykania systemu, ale to dlatego, że wtedy ramdisk zapisuje 2 pliki po 1GB każdy.

Niestety plik wymiany, który przez jakiś czas szczęśliwie rezydował na ramdisku - z niewyjaśnionych powodów wrócił na C:/ i nie mogę tego zmienić (w ustawieniach nadal na c: go nie ma, a jest na ramdisku - ale ustawienia jedno, a system robi swoje i tworzy sobie "na dziko" plik na c:. Jedyne co mogłem zrobić to usankcjonować to ustawieniami i ustalić jego rozmiar na minimalny).

No tak, ponieważ cały dysk masz zapisany po brzegi "losowymi" danymi, to wear levelling ani trim działać nie może. Fizycznie to niemożliwe.

Ja jestem przeciwnikiem szyfrowania całych dysków, czy to HDD czy SSD - moim zdaniem to rozwiązanie dobre jedynie w przypadku rzeczywistego zagrożenia wykradzenia rzeczywiście poufnych danych. Do użytku domowego zupełnie wystarczy mieć wydzielone zaszyfrowane miejsce.

Jedynie szyfrowanie na poziomie systemu plików przejdzie na SSD. :taktak:

To ja teraz trochę skomplikuję sytuację. Polećcie SSD pod system, który jest w całości zaszyfrowany TrueCryptem!

Wczoraj właśnie sobie zaszyfrowałem partycję systemową na Vertex 2. I czuję, że dyskowi to nie służy.

Niestety (ale i stety ze względu na bezpieczeństwo) nie zostawiłem niezaszyfrowanego miejsca dla wear-levellingu, tak jak radzą tu: http://media-addicted.de/ssd-and-tru...ce-issues/744/

Wprawdzie podczas zwykłej pracy nie odczuwam pogorszenia (ale to też dlatego, że co się da mam na RAM-Disku), ale wyniki testów są po prostu dramatyczne (w niektórych zapis jest 10x wolnieszy niż przed zaszyfrowaniem). Znacznie gorsze niż tu: http://blog.siyuz.net/2010/11/17/tru...0a-fde-on-ssd/ (polecam ten artykuł). Dramatycznie spadła też prędkość odczytu losowego małych bloków (np. 4K QD32 w Crystal Mark - spadek ze 101 MB/s do 4 MB/s - to nie pomyłka: to 25x wolniej!). Aż się dziwię, że tego nie odczuwam przy ładowaniu systemu i programów.

Co więcej - jest coraz gorzej z każdym kolejnym powtórzeniem danego testu (chyba dlatego, że szybko zapełnia się się rezerwowa, niewidoczna dla systemu przestrzeń zapasowych sektorów). Trochę to przerażające - jeszcze trochę i dysk chyba dosłownie stanie w miejscu (przy zapisach).

Wydaje mi się, że problem jest dość złożony i - IMHO - najbardziej za spowolnienie zapisu odpowiedzialna jest konieczność zapisywania zawsze do komórek o "gęstych" (niekompresowalnych) starych danych do nadpisania (nie ma puli komórek naprawdę pustych), a nieco mniejszym stopniu fakt, że zawsze zapisywane są dane (nowe) niekompresowalne.

Dlatego sądzę, że nawet SSD z chipsetem bez kompresji byłby podatny na ten problem, ale pewnie w mniejszym stopniu niż Sandforce.

Nie chcę teoretyzować - czy ktoś ma własne, praktyczne doświadczenia z pomiarami wydajności SSD zaszyfrowanych TrueCryptem?

Zauważyłem też, że zaszyfrowana partycja jest całkowicie niepodatna na TRIM. Po prostu efekty TRIM-owanie są równe zeru (wcześniej, przed zaszyfrowanie, zawsze można je było łatwo zmierzyć przy pomocy HD Tune).

Polecam też: http://superuser.com/questions/35812...on-with-an-ssd
Bardzo ciekawe też: http://www.anandtech.com/show/2829/8

Niestety albo źle to wszystko rozumiem, ale smutny wniosek jest taki, że każdy SSD będzie znacznie zwalniał po zaszyfrowaniu.

Porównanie - ATTO:
http://forum.cdrinfo.pl/attachment.p...1&d=1327671114

Crystal Mark:
http://forum.cdrinfo.pl/attachment.p...1&d=1327671114

Niestety nie mam screena sprzed zaszyfrowania, ale napiszę jak było:

Seq: 203 MB/s read oraz 68 MB/s write
512K: 192 MB/s read oraz 65 MB/s write
4K: 22 MB/s read oraz 64 MB/s write
4k QD32: 102 MB/s read oraz 65 MB/s write


Różnice, jak widać, miejscami dość szokujące!

W życiu nawet bym nie rozważył magazynowania plików na SSD - zdecydowanie za drogo. :kreci_gl:

Na system i programy - to i owszem. Miło popatrzeć jak XP pokazuje pulpit po 20 sekundach. :czas:

kupowanie ssd na glowny dysk jest ryzykowne

ale na systemowy jak najbardziej polecam

jeden z moich solid3'ow ma juz nalatane 4,555h a najstarszy vertex2e 12,830h

Ciekawy ten samsung.

BTW, ja od zawsze miałem samsungi (talerzowe) i nic się z nimi nie działo.

Efekt degradacji... Nowsze sterowniki radza sobie z tym problemem znacznie lepiej.

Katalog ze 100 plikami wczytuje sie 5 sekund? Hmm... to wydajnosć którą spodziwałbym się od stacji dyskietek.
Być może to jest wina NTFS, ale to nie usprawiedliwienie. Szybki dysk powinien być szybki niezaleznie od warunków.

Coraz bardziej podoba mi sie ten Samsung 830, 80kIOPS.

http://pclab.pl/news47734.html

Miażdży Agility 3, praktycznie 2 razy szybszy. Chyba wiem co kupie ||

Czy to erase to to samo co TRIM? ext4 i btrfs robią to chyba automatycznie.
Według tego:
https://sites.google.com/site/lightr...orssdsonubuntu
Po 3 miesiącach używania SSD Agility 2 na EXT4 nie ma zwolnienia. Ale i tak Samsung jest lepszy.