Proszę o polecenie dysku SSD pod system (XP).
Wystarczy 40 GB, ale chciałbym, aby był technologicznie nowoczesny i szybki.

Windows XP i dysk SSD
nie jest to zbyt dobre połączenie.
Pamięci stosowane w dyskach SSD wymagają aby przed wpisaniem nowej wartości
stara zawartość danej komórki była wymazana.
W przypadku dysków magnetycznych, gdy usuwałeś plik z dysku
wystarczyło aby system zaznaczył że dany plik nie jste już używany,
różne systemy plików robiły to w inny sposób, poprzez zmiane nazwy pliku,
zmiane któregoś z atrybutów w strukturze opisującej plik,
modyfikacje bitmapy lub b-tree opisującego strukture dysku.
W przypadku dysków SSD to nie wystarcza
jak już powiedziałem, sama zawartość musi zostać wymazana.
Producenci dyskó wprowadzili więc nową komende do protokołu ATA
zaznaczjącą iż dany fragment dysku jest nie używany
i w wolnej chwili można go wymazać.
Instrukcja nazywa się TRIM.
Większość obecnie produkowanych dysków obsługuje TRIM
w innych potrzebna jest aktualizacja firmware aby go dodać.
Gorzej jest o obsługe TRIM od strony systemu operacyjnego.
Windows XP oraz Vista nie wiedzżą nic o TRIM
dopiero w Windows 7 i Windows Server 2008 R2 została dodana obsługa tej komendy
W przypadku linuxa potrzebujesz jądro w wersji 2.6.33
oraz system plików ext4 lub btrfs
Jaki jest rezultat braku wsparcia tej komenty w systemach
spadek prędkości zapisu, spada ona prawie o połowe.
Szukając więc dysku, zwróć uwage
czy producent dodaje do niego oprogramowanie dla Windows XP
które zastępuje brak wsparcia dla TRIM w tym systemie.
--
__________
Pozdrawiam
Robert Winkler

Windows XP i dysk SSD nie jest to zbyt dobre połączenie.

(...)

Szukając więc dysku, zwróć uwage czy producent dodaje do niego oprogramowanie dla Windows XP które zastępuje brak wsparcia dla TRIM w tym systemie.

Wiem o TRIM (niestety ogólnikowo) i wiem, że istnieją programy dla XP, które zastępują brak wsparcia tego systemu dla TRIM. Sądziłem jednak, że są to programy uniwersalne, a nie dla konkretnego modelu dysku.

A więc konkretnie - myślę o OCZ Vertex2 OCZSSD2-2VTX40G (2,5", 40GB, SATA/300).
Czy do niego znajdę "trimmer" pod XP?

Jestem też ciekawy, co się dzieje, jeśli system zna TRIM (np. Win7) ale dysk tego nie obsługuje? A przecież takie dyski były no i są. Czy dzieje sie wtedy mniej więcej to samo, co pod XP + dysk majacy TRIM?

Chciałbym też zapytać o to jak (w praktyce) działają pod XP takie programy do robienia TRIM? Jak często trzeba je odpalać? Jak długo działają? Czy to jest działanie na zasadzie skanowania całego dyski SSD, czy jakieś inne, szybsze operacje?

Bardzo też bym chciał zrozumieć istotę problemu. Bo tak na chłopski rozum - skoro po skasowaniu pliku komórki nie są od razu oznaczane jako wolne, to spadać powinna... wolna pojemność dysku, a nie jego wydajność. Dlaczego jednak tak się dzieje?

Dzięki,

latet

On 2011-08-30 09:23, Latet wrote:

Windows XP i dysk SSD nie jest to zbyt dobre połączenie.

(...)

Szukając więc dysku, zwróć uwage czy producent dodaje do niego
oprogramowanie dla Windows XP które zastępuje brak wsparcia dla TRIM w
tym systemie.

Wiem o TRIM (niestety ogólnikowo) i wiem, że istnieją programy dla XP,
które zastępują brak wsparcia tego systemu dla TRIM. Sądziłem jednak, że
są to programy uniwersalne, a nie dla konkretnego modelu dysku.

A więc konkretnie - myślę o OCZ Vertex2 OCZSSD2-2VTX40G (2,5", 40GB,
SATA/300).
Czy do niego znajdę "trimmer" pod XP?

Microsoft celowo tego nie wprowadza pod XP, technicznie nie ma przeciwskazan. Nie znam oprogramowania udostepniajace TRIM pod XP.

Sa jakies garbage-collectory, ale w to sie trzeba wczytac. Czy aby na pewno koniecznoscia jest stosowanie XP?

Jestem też ciekawy, co się dzieje, jeśli system zna TRIM (np. Win7) ale
dysk tego nie obsługuje? A przecież takie dyski były no i są. Czy dzieje
sie wtedy mniej więcej to samo, co pod XP + dysk majacy TRIM?

Jezeli dysk nie zna TRIM (wszystkie HDD i jakies przepotopowe SSD), to w przypadku SSD faktycznie mamy doczynienia ze spowolnieniem dzialania, chyba ze producent udostepnia dodatkowe oprogramowanie jak pod OCZ Vertex (nie vertex2). dla HDD nie ma to znaczenia

Chciałbym też zapytać o to jak (w praktyce) działają pod XP takie
programy do robienia TRIM? Jak często trzeba je odpalać? Jak długo
działają? Czy to jest działanie na zasadzie skanowania całego dyski SSD,
czy jakieś inne, szybsze operacje?

Nie znam takich programow.

Bardzo też bym chciał zrozumieć istotę problemu. Bo tak na chłopski
rozum - skoro po skasowaniu pliku komórki nie są od razu oznaczane jako
wolne, to spadać powinna... wolna pojemność dysku, a nie jego wydajność.
Dlaczego jednak tak się dzieje?

TRIM w os musi byc zintegrowany z systemem plikow, wtedy np. przy kasowaniu plikow oznacza konkretne bloki jako wolne i dysk nie musi ich zapisywac przy zapisie pojedynczego sektora

Nie znam oprogramowania udostepniajace TRIM pod XP.

*** Szukając więc dysku, zwróć uwage czy producent dodaje do niego oprogramowanie dla Windows XP które zastępuje brak wsparcia dla TRIM w tym systemie.

No to istnieją, czy nie istnieją? :-/
Mniejsza o ich nazwę i metodę działania - ważny jest efekt - zapobieganie spadkowi wydajności dysku...

latet

On 08/30/11 10:17, Latet wrote:

No to istnieją, czy nie istnieją? :-/

Istnieją, ale są przypisane sztucznie do produktu danego producenta
(np. Intel Solid State Drive Toolbox).

Można też odpalić co jakiś czas live CD - i użyć hdparma. Operacja
trwa zwykle ułamek sekundy.

pozdrowienia,
shadow

On 30.08.2011 11:50, Tomasz Potega wrote:

On 08/30/11 10:17, Latet wrote:

No to istnieją, czy nie istnieją? :-/

Istnieją, ale są przypisane sztucznie do produktu danego producenta
(np. Intel Solid State Drive Toolbox).

Można też odpalić co jakiś czas live CD - i użyć hdparma. Operacja
trwa zwykle ułamek sekundy.

W jaki sposob?

TRIM calej wolnej powierzchni w ulamek sekundy nie jest mozliwy.


--
Tomasz Chmielewski
http://wpkg.org

On 08/30/11 12:29, Tomasz Chmielewski wrote:

W jaki sposob?

TRIM calej wolnej powierzchni w ulamek sekundy nie jest mozliwy.

Dlaczego?

Aplikacja tworzy plik (zajmujący maksymalnie dużą przestrzeń), pobiera
od systemu listę bloków, które zajął - i trimuje sektory, na które się
to przekłada - bo wiadomo, że nie zawierają żadnych sensownych danych.

pozdrowienia,
shadow

TRIM calej wolnej powierzchni w ulamek sekundy nie jest mozliwy.

Dlaczego?
Aplikacja tworzy plik (zajmujący maksymalnie dużą przestrzeń), pobiera
od systemu listę bloków, które zajął - i trimuje sektory, na które się
to przekłada - bo wiadomo, że nie zawierają żadnych sensownych danych.

Sprytne...!

A czy podobny myk byłby możliwy spod Win7?
Mam na mysli podłączenie dysku SSD (na co dzień używanego jako systemowy pod XP) jako drugiego dysku do kompa z Win7 - i wykonanie podobnej operacji. Założyć parę wielkich plików nawet ręcznie i zaraz je skasować - to żaden problem.

Dlaczego chciałbym to robić spod Win7? Bo nie znam się na tych linuxach i nie sądzę, abym sobie poradził z tym odpalając LiveCD, chyba, że gdzieś istniałaby instrukcja krok po kroku.

Pozdrawiam,

latet

TRIM calej wolnej powierzchni w ulamek sekundy nie jest mozliwy.

Aplikacja tworzy plik (zajmujący maksymalnie dużą przestrzeń), pobiera
od systemu listę bloków, które zajął - i trimuje sektory, na które się
to przekłada

Ale zaraz zaraz... Trimuje tzn. wysyła polecenie TRIM (wraz z listą sektorów). Ale dysk takie polecenie może wykonać w tzw. "wolnej chwili". Czyli kiedy? I czy wiadomo, kiedy to ukończy? Pytanie bardzo praktyczne - kiedy można już tego linuxa z live CD wyłączyć i wrócić do normalnej pracy pod XP...

latet

On 08/30/11 13:02, Latet wrote:

Ale zaraz zaraz... Trimuje tzn. wysyła polecenie TRIM (wraz z listą
sektorów). Ale dysk takie polecenie może wykonać w tzw. "wolnej chwili".
Czyli kiedy? I czy wiadomo, kiedy to ukończy? Pytanie bardzo praktyczne
- kiedy można już tego linuxa z live CD wyłączyć i wrócić do normalnej
pracy pod XP...

Większość dysków uaktualni po prostu listę wolnych bloków, AFAIR kiedyś
tylko kontroler Toshiby "mocno później" realizował TRIM.

I tak, można kombinować i z poziomu Windows 7:

http://www.ocztechnologyforum.com/forum/showthread.php?73888

Znalazłoby się pewnie i coś vendor-agnostic pod XP, ale trzeba
poszukać (nie wiem, czy O&O czegoś nie miał)...

pozdrowienia,
shadow

Czyli kiedy? I czy wiadomo, kiedy to ukończy? Pytanie bardzo praktyczne
- kiedy można już tego linuxa z live CD wyłączyć i wrócić do normalnej
pracy pod XP...

Większość dysków uaktualni po prostu listę wolnych bloków

No zaraz... ale czy TRIM nie ma polegać na ich fizycznym opróżnieniu? Kiedy to się stanie?

latet

P.S. Czy dyski SSD działają tak, że zawsze w pierwszej kolejności zapisują do komórek, które są wyzerowane, a dopiero gdy takich zabraknie - do takich, w których jeszcze są dane, ale przez system już uznane za skasowane? Czy też jest inaczej - to system decyduje, gdzie plik ma być fizycznie zapisany, więc może być tak, że puste komórki jeszcze są, ale dysk już się musi męczyć z czasochłonnymi zapisami read-modify-write.
Dziękuję,
latet

Dnia Tue, 30 Aug 2011 14:34:21 +0200, Latet napisał(a):

P.S. Czy dyski SSD działają tak, że zawsze w pierwszej kolejności zapisują do komórek, które są wyzerowane, a dopiero gdy takich zabraknie - do takich, w których jeszcze są dane, ale przez system już uznane za skasowane? Czy też jest inaczej - to system decyduje, gdzie plik ma być fizycznie zapisany, więc może być tak, że puste komórki jeszcze są, ale dysk już się musi męczyć z czasochłonnymi zapisami read-modify-write.

Masz potezne pragnienie wiedzy, grupa to moze byc za malo, moze sprobuj
tutaj:

http://www.tinyurl.pl?yzts2wtr

MSPANC :-P

--
pozdro
RemeK

On 30.08.2011 12:37, Tomasz Potega wrote:

On 08/30/11 12:29, Tomasz Chmielewski wrote:

W jaki sposob?

TRIM calej wolnej powierzchni w ulamek sekundy nie jest mozliwy.

Dlaczego?

Aplikacja tworzy plik (zajmujący maksymalnie dużą przestrzeń), pobiera
od systemu listę bloków, które zajął - i trimuje sektory, na które się
to przekłada - bo wiadomo, że nie zawierają żadnych sensownych danych.

Dokladnie.

1) tworzenie pliku zajmujacego cala wolna przestrzen nie trwa ulamek sekundy, ale wiele minut, w zaleznosci od pojemnosci dysku

2) skasowanie tego pliku wywola TRIM, lecz dysk w tle i tak musi wyzerowac wolna przestrzen


Nie ma mowy o zrobieniu tego w ulamki sekund, czy nawet sekundy.

--
Tomasz Chmielewski

On 09/02/11 13:48, Tomasz Chmielewski wrote:

1) tworzenie pliku zajmujacego cala wolna przestrzen nie trwa ulamek
sekundy, ale wiele minut, w zaleznosci od pojemnosci dysku

Ale nie musisz tego pliku wypełniać (sparse file) - chodzi tylko
o możliwie najprostsze pobranie listy dostępnych sektorów.

2) skasowanie tego pliku wywola TRIM, lecz dysk w tle i tak musi
wyzerowac wolna przestrzen

Pod XP kasowanie nie wywoła TRIMa - a od tego chyba wyszliśmy.

Nie ma mowy o zrobieniu tego w ulamki sekund, czy nawet sekundy.

Praktyka raczy się z Tobą nie zgodzić ;)

pozdrowienia,
shadow

Dnia Fri, 02 Sep 2011 14:13:28 +0200, Tomasz Potega napisał(a):

Ale nie musisz tego pliku wypełniać (sparse file) - chodzi tylko o
możliwie najprostsze pobranie listy dostępnych sektorów.

Sparse file to nie plik z pustymi sektorami, a plik z pustą listą sektorów.

On 09/02/11 14:18, jureq wrote:

Sparse file to nie plik z pustymi sektorami, a plik z pustą listą
sektorów.

Bo nikt nie tworzy pliku z pustymi sektorami (jeśli nie musi),
a tylko gwarantuje przypisanie plikowi powierzchni na dysku.
I robi wszystko, by jak najmniej go dotykać - plik jest potrzebny
tylko i wyłącznie do uzyskania listy wolnych sektorów.

pozdrowienia,
shadow

Dnia Fri, 02 Sep 2011 14:23:20 +0200, Tomasz Potega napisał(a):

Sparse file to nie plik z pustymi sektorami, a plik z pustą listą
sektorĂłw.

Bo nikt nie tworzy pliku z pustymi sektorami (jeśli nie musi), a tylko
gwarantuje przypisanie plikowi powierzchni na dysku. I robi wszystko, by
jak najmniej go dotykać - plik jest potrzebny tylko i wyłącznie do
uzyskania listy wolnych sektorĂłw.

Więc właśnie ci piszę, że sparse file nie będzie zawierał listy pustych sektorów. Żaden znany mi system plików nie przydziela sektorów dla sparse file. I żaden nie gwarantuje pustych sektorów dla takiego pliku. W szczególności sparse file może być "logicznie" większy od pojemności dysku.

On 09/02/11 14:31, jureq wrote:

Więc właśnie ci piszę, że sparse file nie będzie zawierał listy pustych
sektorów. Żaden znany mi system plików nie przydziela sektorów dla sparse
file. I żaden nie gwarantuje pustych sektorów dla takiego pliku. W
szczególności sparse file może być "logicznie" większy od pojemności
dysku.

W szczególności możesz też posiłkować się fallocate()...
Pojechałem skrótem, i nie zauważyłem skórki od banana.

pozdrowienia,
shadow

No to istnieją, czy nie istnieją? :-/

Istnieją, ale są przypisane sztucznie do produktu danego producenta
(np. Intel Solid State Drive Toolbox).

A jak się to ma do tego:
"Kingston przedstawia SSD z własnym TRIM-em dla użytkowników Windows XP i nie tylko"
http://pclab.pl/news43753.html

Artykuł zachęcający (choć stary), ale komentarze pod nim twierdzą, że to jakaś ściema...?
Czy ktoś coś bliżej wie na ten temat?

A jak to wygląda w przypadku OCZ Velocity2 i 3? Są takie narzędzia, czy nie ma?

Dzięki,

latet

Istnieją, ale są przypisane sztucznie do produktu danego producenta
(np. Intel Solid State Drive Toolbox).

Tu jest o nim więcej.
http://download.intel.com/design/flash/nand/mainstream/Intel_SSD_Optimizer_White_Paper.pdf

Ale mam praktyczne pytanie - jak rozpoznać (przed zakupem), czy dany dysk może działac z tym narzędziem?

latet

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

Istnieją, ale są przypisane sztucznie do produktu danego producenta
(np. Intel Solid State Drive Toolbox).

Tu jest o nim więcej.
http://download.intel.com/design/flash/nand/mainstream/Intel_SSD_Optimizer_White_Paper.pdf

Ale mam praktyczne pytanie - jak rozpoznać (przed zakupem), czy dany dysk może działac z tym narzędziem?

Poszukać w wynikach testów.

TRIM w os musi byc zintegrowany z systemem plikow, wtedy np. przy
kasowaniu plikow oznacza konkretne bloki jako wolne i dysk nie musi ich zapisywac przy zapisie pojedynczego sektora

A plik swap na dysku SSD?
Nie wiem dokładnie jak Windows (choćby 7) go obsługuje, ale wyobrażam to sobie tak, że raczej aktualizuje jego zawartość, a nie kasuje fragmenty, tak jak kasuje pliki - tak więc pewnie nawet TRIM nie bardzo jest w stanie zapewnić dobrą wydajność pliku wymiany leżącego na SSD? Z drugiej strony - pewnie i tak będzie lepsza niż na hdd ze względu na czasy dostępu...

latet

On 2011-08-30 10:26, Latet wrote:

TRIM w os musi byc zintegrowany z systemem plikow, wtedy np. przy
kasowaniu plikow oznacza konkretne bloki jako wolne i dysk nie musi
ich zapisywac przy zapisie pojedynczego sektora

A plik swap na dysku SSD?
Nie wiem dokładnie jak Windows (choćby 7) go obsługuje, ale wyobrażam to
sobie tak, że raczej aktualizuje jego zawartość, a nie kasuje fragmenty,
tak jak kasuje pliki - tak więc pewnie nawet TRIM nie bardzo jest w
stanie zapewnić dobrą wydajność pliku wymiany leżącego na SSD? Z drugiej
strony - pewnie i tak będzie lepsza niż na hdd ze względu na czasy
dostępu...

Przy częstych i małych zapisach w losowe miejsca (swap), moze warto rozwazyc umieszczenie go na innym dysku (niektorzy wrecz polecaja wylaczenie swap, ale to moze generowac problemy), ale majac dwa dyski IMHO najlepszym rozwiazaniem jest wrzucenie swapa na drugi.

W windowsach jak nabardziej wykonalne przez klikanie.

Przy częstych i małych zapisach w losowe miejsca (swap), moze warto rozwazyc umieszczenie go na innym dysku (niektorzy wrecz polecaja wylaczenie swap, ale to moze generowac problemy), ale majac dwa dyski IMHO najlepszym rozwiazaniem jest wrzucenie swapa na drugi.

Kurcze, to zła wiadomość...
Często odczuwam "mulenie" systemu właśnie w sytuacjach, gdy intensywnie korzysta ze swapa. Liczyłem głównie na to, że umieszczenie swapa na SSD da systemowi kopa... A Ty piszesz, że wręcz się nie zaleca go tam umieszczać. Z drugiej strony - czytałem wczoraj coś o tweakowaniu SSD pod XP i tam pisali, żeby jednak swapa na nin pozostawić.

latet

A tak w ogóle, to jak ważki jest to problem? Czyli - o ile różni się prędkość zapisu na nowiutki SSD od prędkości zapisu na zapełniony i wykasowany bez trim?

P.S. A czy jest też różnica pomiędzy zapisem do komórek fabrycznie pustych, a do komórek poprawnie wyzerowanych przez TRIM?

On 30.08.2011 14:23, Latet wrote:

A tak w ogóle, to jak ważki jest to problem? Czyli - o ile różni się
prędkość zapisu na nowiutki SSD od prędkości zapisu na zapełniony i
wykasowany bez trim?

W teorii roznica powinna byc mniej wiecej dwukrotna.

Aby nagrac cokolwiek do komorki flash, musi byc ona najpierw wyzerowana.

Gdy nie byl uzywany trim, dysk wykonuje dwie operacje na danej komorce (zerowanie + zapis).

Gdy uzywany byl trim, wykonywana jest tylko jedna operacja (zapis).

P.S. A czy jest też różnica pomiędzy zapisem do komórek fabrycznie
pustych, a do komórek poprawnie wyzerowanych przez TRIM?

Nie.


--
Tomasz Chmielewski
http://wpkg.org

Użytkownik "Tomasz Chmielewski" <tch@nospam.wpkg.org> napisał w wiadomości news:9cbubiF3sbU2mid.uni-berlin.de...

On 30.08.2011 14:23, Latet wrote:

A tak w ogóle, to jak ważki jest to problem? Czyli - o ile różni się
prędkość zapisu na nowiutki SSD od prędkości zapisu na zapełniony i
wykasowany bez trim?

W teorii roznica powinna byc mniej wiecej dwukrotna.

Chyba dużo większa. Dysk bez możliwości szybkiego zapisu praktycznie staje.

Bardzo też bym chciał zrozumieć istotę problemu. Bo tak na chłopski rozum - skoro po skasowaniu pliku komórki nie są od razu oznaczane jako wolne, to spadać powinna... wolna pojemność dysku, a nie jego wydajność. Dlaczego jednak tak się dzieje?

Chyba sam sobie już na to odpowiem. Po prostu wolniej trwa zapis, gdy tuż przed jego wykonaniem trzeba jeszcze wyzerować komórkę pamięci. Szybiej jest, gdy zerowanie zwolnionych komórek odbywa się wcześniej (" w wolnej chwili "). Domyślam się więc, że komenda TRIM wysyłana jest do dysku (wraz z konkretnym adresem zwalninych komórek) za każdym razem, gdy coś zostaje skasowane, a dysk trzyma sobie to w jakiejś kolejce i wykonuje "w wolnej chwili". Podejrzewam więc też  , że nardzędzie zapewniajace TRIM pod XP musi działać cały czas w tle, można więc je niemalże nazwać sterownikiem do konkretnego dysku...
Mam rację?

latet

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

Bardzo też bym chciał zrozumieć istotę problemu. Bo tak na chłopski rozum - skoro po skasowaniu pliku komórki nie są od razu oznaczane jako wolne, to spadać powinna... wolna pojemność dysku, a nie jego wydajność. Dlaczego jednak tak się dzieje?

Chyba sam sobie już na to odpowiem. Po prostu wolniej trwa zapis, gdy tuż przed jego wykonaniem trzeba jeszcze wyzerować komórkę pamięci. Szybiej jest, gdy zerowanie zwolnionych komórek odbywa się wcześniej (" w wolnej chwili ").

Zabawnie brzmi ten festiwal ignorancji. A przecież informacje skąd się biorą problemy z zapisem są dostępne w Internecie. Chociażby w postaci bardzo łopatologicznego artykułu na stronach ananda. Nie zmyślać, poczytać.

Mam rację?

Nie.

Chyba sam sobie już na to odpowiem. Po prostu wolniej trwa zapis, gdy tuż przed jego wykonaniem trzeba jeszcze wyzerować komórkę pamięci. Szybiej jest, gdy zerowanie zwolnionych komórek odbywa się wcześniej (" w wolnej chwili ").

Zabawnie brzmi ten festiwal ignorancji. A przecież informacje skąd się biorą problemy z zapisem są dostępne w Internecie. Chociażby w postaci bardzo łopatologicznego artykułu na stronach ananda. Nie zmyślać, poczytać.

Mam rację?

Nie.

Ciekawe, bo przeczytałem dokładnie to:
http://download.intel.com/design/flash/nand/mainstream/Intel_SSD_Optimizer_White_Paper.pdf
i potwierdza to w zasadzie to, co napisałem wyżej. Może nie wyraziłem tego fachowymi słowami, ale ogólnie przecież w tym rzecz.

latet

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

Chyba sam sobie już na to odpowiem. Po prostu wolniej trwa zapis, gdy tuż przed jego wykonaniem trzeba jeszcze wyzerować komórkę pamięci. Szybiej jest, gdy zerowanie zwolnionych komórek odbywa się wcześniej (" w wolnej chwili ").

Zabawnie brzmi ten festiwal ignorancji. A przecież informacje skąd się biorą problemy z zapisem są dostępne w Internecie. Chociażby w postaci bardzo łopatologicznego artykułu na stronach ananda. Nie zmyślać, poczytać.

Mam rację?

Nie.

Ciekawe, bo przeczytałem dokładnie to:
http://download.intel.com/design/flash/nand/mainstream/Intel_SSD_Optimizer_White_Paper.pdf
i potwierdza to w zasadzie to, co napisałem wyżej.

Tamten tekst niczego nie potwierdza, jest zwykłym marketingowym bełkotem. Pewnie nie wiesz, ze Intel używa w charakterze trymera starego dosowskiego programu HDDERASE? Szkoda, że juz tego nie pisze.

Może nie wyraziłem tego fachowymi słowami, ale ogólnie przecież w tym rzecz.

Nie, rzecz jest w czymś całkiem innym. W różnicy wielkości pomiędzy liczbą komórek którą się zapisuje (lub odczytuje) na raz, a liczbą, którą się kasuje. Po prostu nie można skasować tylko jednego zapisu. I to jest praprzyczyną problemów.

Nie, rzecz jest w czymś całkiem innym. W różnicy wielkości pomiędzy liczbą komórek którą się zapisuje (lub odczytuje) na raz, a liczbą, którą się kasuje. Po prostu nie można skasować tylko jednego zapisu. I to jest praprzyczyną problemów.

Wiem o tym, że strony (np. 4 KB) pogrupowane są w bloki wielkości nawet np. 512 KB i że sprzęt nie zapisuje na raz mniej niż całego bloku. Ale jak w tym ma pomóc TRIM, to już nie rozumiem. Byłbym bardzo wdzięczny za wytłumaczenie.

Jest też na WIKI opis TRIM i najważniejszego fragmentu (tego od słów "After that..." do końca - kompletnie nie rozumiem) :

The TRIM command is designed to enable the operating system to notify the SSD of which pages of data are now invalid due to erases by the user or operating system itself. During a delete operation the OS will not only mark the sectors as free for new data, but it will also send a TRIM command to the SSD with the associated LBAs to be marked as no longer valid. After that point the SSD knows not to relocate the data in those LBAs during garbage collection. This will result in fewer writes to the flash enabling a lower write amplification and longer endurance.

Czytałem też, że niekóre SSD posiadają własne, wewnętrzne, niezależne od TRIM mechanizmy i - jak twierdzą niektórzy - w ich przypadku stosowanie TRIM jest zupełnie niepotrzebne.

Spotkałem się też z opinią, że TRIM sam w sobie (nie tylko ze względu na czas jego wykonania) potrafi nieźle przymrozić system.

Z góry dzięki za rozstrzygające objasnienia :-)

latet

On 2011-09-01 08:50, Latet wrote:

Nie, rzecz jest w czymś całkiem innym. W różnicy wielkości pomiędzy
liczbą komórek którą się zapisuje (lub odczytuje) na raz, a liczbą,
którą się kasuje. Po prostu nie można skasować tylko jednego zapisu. I
to jest praprzyczyną problemów.

Wiem o tym, że strony (np. 4 KB) pogrupowane są w bloki wielkości nawet
np. 512 KB i że sprzęt nie zapisuje na raz mniej niż całego bloku. Ale
jak w tym ma pomóc TRIM, to już nie rozumiem. Byłbym bardzo wdzięczny za
wytłumaczenie.

To nie jest do konca prawda. Flash EPROM mozna zapisywac w mniejszych obszarach, ale tylko raz. ponowny zapis wymaga wymazania calego bloku

Jak juz pisalem. ponowny zapis sektora do takiego bloku wymaga:
- odczytania sektorow bloku, *ktore sa wykorzystywane*
- wykasowania calego bloku
- zapisania calego lub czesci, o ktorej sterwonik ma informacje, ze jest uzywana z uwzglednieniem zmian (to co faktycznie zapisujemy)

TRIM - pozwala ograniczyc ilosc operacji odczytu i zapisu, poniewaz wiadomo ktore sektory sa istotne, ktore nie.

to tak w skrocie i generalnie do kosci pamieci. W praktyce obecne *uklady kontrolujace SSD* moga sobie dowolnie mapowac bloki w ramach wlasnej przestrzeni, tu juz sie nie wypowiadam (algorytmy ulegaja zmianie w czasie). Celem jest przede wszystkim zrownowazenie ilosci operacj zapisu pomiedzy wszystkimi komorkami pamieci - to przedluza zywotnosc calego dysku. Innymi slowy jezeli zapisujemy sektor A, raz znajduje sie w jednym fizycznym miejscu, po zapisie w zupelnie innej kosci pamieci (to tak np.)

Implementacja komend ATA moze byc rozna w zaleznosci od dysku, wiec nie posuwalbym sie do generalizowania. to potencjalnie nowy produkt na rynku, wiec opinie o dyskach produkowanych 1-2 lata temu moga zupelnie nie pasowac do obecnej sytuacji

latet

Użytkownik "Rafał" <rafalweb@lukawski.pl> napisał w wiadomości
news:j3nfht$q0v$1news.onet.pl...

On 2011-09-01 08:50, Latet wrote:

Nie, rzecz jest w czymś całkiem innym. W różnicy wielkości pomiędzy
liczbą komórek którą się zapisuje (lub odczytuje) na raz, a liczbą,
którą się kasuje. Po prostu nie można skasować tylko jednego zapisu. I
to jest praprzyczyną problemów.

Wiem o tym, że strony (np. 4 KB) pogrupowane są w bloki wielkości nawet
np. 512 KB i że sprzęt nie zapisuje na raz mniej niż całego bloku. Ale
jak w tym ma pomóc TRIM, to już nie rozumiem. Byłbym bardzo wdzięczny za
wytłumaczenie.

To nie jest do konca prawda. Flash EPROM mozna zapisywac w mniejszych
obszarach, ale tylko raz. ponowny zapis wymaga wymazania calego bloku
Jak juz pisalem. ponowny zapis sektora do takiego bloku wymaga:
- odczytania sektorow bloku, *ktore sa wykorzystywane*
- wykasowania calego bloku
- zapisania calego lub czesci, o ktorej sterwonik ma informacje, ze jest
uzywana z uwzglednieniem zmian (to co faktycznie zapisujemy)

Jak z tego widać mamy dwa rodzaje zapisu. Szybki, do niezapisanej strony,
oraz wolny. Wolny ma miejsce wtedy, kiedy trzeba skorzystać ze strony
niepotrzebnej ale jeszcze nie skasowanej. Wyglada to tak. Wczytuje się cały
blok danych do bufora, sam blok zostaje skasowany, zawartość bufora jest
uzupełniana o nowe strony do zapisania i całość jest wpisywana do przed
chwilą skasowanego bloku.  To trwa o wiele dłużej niż szybki zapis
bezpośredni.

TRIM - pozwala ograniczyc ilosc operacji odczytu i zapisu, poniewaz
wiadomo ktore sektory sa istotne, ktore nie.

W czasie normalnej pracy w blokach powstają liczne dziury w postaci
zwolnionych, ale jeszcze nieskasowanych stron. Trymowanie stara się tak
przenosić dane, żeby zajmowały jak najmniej bloków. A resztę kasuje. W ten
sposob powiększa ilość stron gotowych do szybkiego zapisu.