🚀 go-pugleaf

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...