> 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

do góry

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

do góry

P.S.
Czy komenda TRIM działa w trybie IDE, czy dysk musi pracować w trybie AHCI?

Pozdrawiam,

latet

do góry

Użytkownik "Rafał" <r...@l...pl> napisał w wiadomości
news:j3nfht$q0v$1@news.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.

do góry

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

do góry

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

do góry

Użytkownik "Tomasz Chmielewski" <t...@n...wpkg.org> napisał w wiadomości
news:9cbubiF3sbU2@mid.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.

do góry

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

do góry

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.

do góry

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

do góry