piątek, 11 listopada 2022 o 18:43:51 UTC-6 Marcin Debowski napisał(a):
> On 2022-11-11, ptoki (ptoki) <sczy...@gmail.com> wrote:
> > czwartek, 10 listopada 2022 o 21:34:02 UTC-6 Marcin Debowski napisał(a):
> >> On 2022-11-10, ptoki (ptoki) <sczy...@gmail.com> wrote:
> >
> >> > W twoim scenariuszu te 30% niespartycjonowane bylo uzywane przez dysk
> >> > do rozpraszania zapisow. I w praktyce yo co zapisywales na tych 70%
> >> > trafialo na te pozostale 30% bo dysk wiedzial ze sa nie uzyte.
> >> > Wiedzial o tym bo ich nie zapisal wczesniej a nie dlatego ze tam nie
> >> > bylo partycji.
> >> Dobrze, to teraz jeszcze takie coś. Podmontowałem tą nieużywaną
> >> partycję i zapuściłem ręcznie fstrima. Ztrimował 165GB/175GB
> >> dostępnych.
> > fstrim dziala dziwnie. Kiedys pisalem se z autorem i jego tlumaczenie
> > co i jak bylo tak metne ze odpuscilem konwersacje.
> >
> > Mialem wtedy do niego pytanie jakim cudem fstrim puszczony raz
> > zwalnia 56GB, puszony natychmiast drugi raz zwalnia 0 bajtow, kolejne
> > puszczenie i znowu 0 bajtow i na kolejnym zwolnione 0.8GB podczas gdy
> > iostat pokaywal ledwo 20MB zapisane.
> Gdzieś się coś nie kaszuje i uwalnia z dużym opóźnieniem? W sensie, że
> iostat o bieżących operacjach a gdzieś siedzi w jakimś buforze 0.8GB i
> dopiero po dłuższym czasie zostaje fizycznie zapisane?
Nie wiem, mysle ze nie. Probowalem sie wywiedziec od lolka co pisal fstrim i
przegladalem kod i nie dowiedzialem sie czemu takie dziwne zachowanie jest.
A jest na roznych kompach, z roznymi systemami. I wiem ze jakby lolek od
fstrima chcial to by zreplikowal moj eksperyment w doslownie 2 minuty.
Jego tlumaczenia byly po prostu powtarzaniem tego co w kodzie i na stronie.
Obstawiam ze on zaimplementowal to tak jak gdzies napisano bez zbytniego
testowania i ogladu.
A no i to samo jest na roznych dyskach. Od jakichs cruciali, poprzez samsungi
az po kingstony.
I jeszcze, gdyby fstrim zwalnial mniej niz pokazuje iostat to bym zalozyl ze
moze OS robi cos a fstrim nie ma szansy na zwolnienie bo OS to zrobil.
Ale jest zazwyczaj odwrotnie.
Moze, moze, ogromne moze podczas operacji IO jest wysylane cos w rodzaju
"zapisz 3 bajty ale zaznacz caly blok za zapisany" i fstrim zwalnia caly blok i
dlatego opmpuje numerki ale to jest niekonsystentne nawet tak.
Bo operacja IO jest jedna czy piec na krzyz i zapisow jest na 300kB a fstrim
zwalnia np. 20MB.
Nie klei sie to zupelnie.
No i na koniec to mimo ze fstrim biega caly czas to moglem jakims cudem odwolac
te bloki recznie i dysk dostal kopa. Smierdzaca sprawa.
> Czym można z lini poleceń sprawdzić wydajność odczytów w jakiś rozsądny
> sposób? Czy masz na myśli przeczytanie całego urządzenia np. dd? Bo
> chyba nie to:
>
> root@agatek:~# hdparm -tT /dev/sda
>
> /dev/sda:
> Timing cached reads: 2498 MB in 2.00 seconds = 1249.94 MB/sec
> Timing buffered disk reads: 1074 MB in 3.00 seconds = 357.78 MB/sec
Hdparm jest slaby do tego. Ja uzywam disks z gui. Tam mozna zapodac ile probek
i jakiej wielkosci ma pobrac z calej powierzchni.
I ladnie widac ktore obszary sa zaafektowane. Jak masz plaski wykres na
poziomie tych 200 czy 25 albo 500MB/sek to dysk jest zdrowy.
Jak wydajnosc opada o polowe albo do 20% tego sufitu to wiadomo ze cos jest nie
tak.
I to wszystko przy odczytach. O zapisach nawet nie wspominam.
> > Jak np. zalozysz partycje pod winda (albo na kompie #1) I zaniesiesz
> > dyska do drugiego kompa albo podepniesz do linuxa i zalozysz partycje
> > od nowa to nie sadze aby linux/windows powiedzial dyskowi ze teraz
> > caly obszar partycji ma byc uznany za pusty. W efekcie mimo nawet
> > dobrze dzialajacego trima dysk sie nie dowie o tym ze spora jego czesc
> > jest nieuzywana i moze robic za wear leveling.
> A ten kontroler to nie powinien być w obrębie ssd i pamiętać takich rzeczy?
Nie, bo trim mowi dyskowi co jest nieuzywane.
A trim z windy nie wie co skasowal linux i odwrotnie.
No i nie wiem czy format mowi ze teraz wszystko na partycji jest nieuzyte zanim
zacznie formatowac.
Ogolnie w tym zakresie nieco kiepsko to wyglada. Trzeba niestety z paranoi
podcierac tym dyskom tylki...
|