On 14/11/2020 15:19, jedrek wrote:
"pioruns" news:rofeee$ovp$1$pioruns@news.chmurka.net
Mam zajete 7.2GB na partycji /, wolnego zostalo 210GB (tyle zajmuje
Debian bez /home i /var :D). Dyski pokazuja 3% i 4% zuzycia komorek w
SMART.
Wolne w sensie, że masz założoną partycję na 100% pojemności dysku?
Tak
I na partycji zostało 210GB wolnego? 210GB to realna pojemność nadrukowanego
250GB na etykiecie SSD? Dalej to liczą dziesiętnie?
Dalej licza, jak liczyli. Tyle, ze Linux Ci pozwala wybrac jakie
jednostki chcesz wyswietlac.
Capacity: 250.06 GB [232.89 GiB, 250059350016 bytes]
A tak mi system zglasza:
Filesystem Size Used Avail Use% Mounted on
/dev/md126 229G 7.2G 210G 4% /
Reszta (~3 GB?) pewnie poszla w Ext4 journal.
Czy raczej założona partycja jakaś mniejsza, np. 20GB a reszta obszaru
nieprzydzielona pod partycje?
Czy założenie jednej wielki partycji o wielkości będącej 100% pojemności
dysku SSD i nie zapychanie jej do końca (czyli przestrzegamy tego, że
"końccowe" ~60GB dla całkowitej pojemności ~210GB - czyli około 30% z
całości) zawsze jest wolne) będzie równoważne ze zrobieniem mniejszej
partycji i pozostawieniu za nią tych wskazanach wcześniej 30% obszaru
nieprzydzielonego?
Tak, ale tylko wtedy jak twoj system obsluguje TRIM.
Co wtedy na tym obszarze nieprzydzielony jest realizowane? To jest coś
ala jakby pamięc wirtualna i najpierw dysk SSD coś tam sobie składa w
całość jakieś bloki czy co? Jest to gdzieś kawa na ławę wyjaśnione abym
zrozumiał, że jest to PRAWIE równoważne z tym, że dany dysk co jakiś
czas traktuje się tym poleceniem TRIM? Oraz co konkretnie się dzieje jak
niby skasowane pliki nadal "Zajmują" według bezTRIMowej logiki miejsce
na dysku. Co się wtedy dzieje w momencie próby zapisu?
Ja rozumiem to tak - moge sie mylic:
Kontroler dysku SSD potrafi czytac tablice partycji i wie tylko gdzie
jest puste, nieprzydzielone miejsce. Wtedy wykorzystuje to miejsce, aby
zapisywac twoje dane tam, zamiast po raz n-ty w tej samej komorce gdzies
w obszarze przydzielonym dla partycji (to sie nazywa write
amplification). Gdyby tego nie robil, to czesto uzywane komorki by
padly, podczas gdy komorki z niepdzydzielonego miejsca sa nadal "nowe".
Ogolnie technika sie nazywa wear leveling i overprovisioning.
SSD niestety nie wie, co sie znajduje wewnatrz systemow plikow - nie
umie interpretowac NTFS, Ext4, Btrfs itd. A wiec nie wie, ile tam jest
miejsca wolnego, ktore moglby wykorzystac.
W czym był problem aby dysk sam sobie w swoim własnym oprogramowaniu
realizował sobie funkcję TRIM bez potrzeby tego wywoływania z zewnętrz,
a dla wszelakich systemów taki SSD był widoczny jako typowy talerzowy
dysk - czyli zachowywałby kompatybilność wsteczną.
Sa kontrolery, co niby same rozumieja systemy plikow, ale ogolnie jest tak:
Jak opisalem powyzej, sam dysk tylko widzi wolne miejsce w postaci
pustych partycji. Jesli chcesz, aby zobaczyl wiecej wolnego miejsca do
wykorzystania podczas pracy, to uzywasz OS obslugujacego TRIM. Wtedy OS
mowi regularnie dyskowi, aby wykorzystywal sobie cale wolne miejsce
*wewnatrz* danej partycji. Czyli dysk ma miejsce gdzie niezaalokowales
zadnych partycji plus wolne miejsce wewnatrz partycji, tak jak mu OS
przykazal. Przy okazji, operacja TRIM permanentnie kasuje zawartosc
komorki. Kazda komorka musi byc najpierw skasowana przed ponownym
zapisem. A wiec TRIM zwieksza tez wydajnosc, bo wszystko juz jest gotowe
do ponownego zapisu. O skasowane komorki SSD "nie dba" i nie odswieza
ich, nie robi background garbage collection, ale wie, ze sa puste i
gotowe do zapisania czegos.
PS. Temat jest bardzo szeroki i moj lopatologiczny opis jest daleki od
idealu. Wszystkie te, ktore uzylem, sa na Wikipedii:
https://en.wikipedia.org/wiki/Trim_(computing)
https://en.wikipedia.org/wiki/Write_amplification
--
pozdrawiam, pioruns
_,.-'~'-.,__,.-'~'-.,__,.-'~'-.,__,.
Registered Linux User #454644
|