On 2022-11-11, ptoki (ptoki) <s...@g...com> wrote:
> czwartek, 10 listopada 2022 o 21:34:02 UTC-6 Marcin Debowski napisał(a):
>> On 2022-11-10, ptoki (ptoki) <s...@g...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?

> Mialem dyska na ktorym fstrim chodzil caly czas i po paru latach
> wydajnosc jego spadla do jakichs smiesznych wartosci na poziomie
> 50MB/sek. Pokasowalem wszystko z niego, puscilem fstrima i wydajnosc
> byla nadal do dupy. Testowalem zwyklym gnomowym disks-em. Tam ladnie
> widac jaka czesc dysku ma jaka wydajnosc.
>
> No i stwierdzilem jak gary oldman w 5elemencie: trza samemu zeby
> dobrze bylo i puscilem ten baszowy skrypt z dolu tego posta
> https://superuser.com/questions/308251/how-to-trim-d
iscard-a-whole-ssd-partition-on-linux
> Albo podobny. Puscilem to na dysku, skonczylo sie w pare chwil. A
> potem puszczalem benchmarka z disks i na bierzaco widzialem jak sie
> wydajnosc podnosi na tych obszarach gdzie jest konkretnie trim
> robiony. Literalnie widzialem jak wydajnosc skacze z tych 50-60MB/sek
> do 250 podczas paru rund benchmarkowania.

Dzięki, pomęcze biedaka jak go już wymienie.

>> Zapuściłem ponownie badblock i liczba bb spadła z 5140 na
>> 770. O ile dobrze rozumiem to fstrim nie zdąrzył się dorwać do tej
>> partycji jak jeszcze przed laty była zamontowana, czyli de facto
>> kontroler myślał, że są to zajęte bloki, czyli pewnie było grubo
>> poniżej 10% wolnych. W takim razie tym dziwniejsze, że on jeszcze żyje
>> i w sumie cały czas bryka. Zapisałem 1-7GB na sda2 i sda1 i prędkości
>> powyżej 250MB/s.
>>
>
> Tak, to dosyc podobny scenariusz jaki mi sie w glowie poukladal. Jak
> mozesz to pusc se blkdiscardy albo te hdparmy i zobacz jaka ma
> wydajnosc odczytow. Jak ma bardzo nierowna to znaczy ze trim pokpil
> temat. Jak caly ma rowno szybkie odczyty to nie jest zle (ale nie
> wiem czy dobrze jest)

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

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

> Pusc sobie iostat-a albo zajrzyj w statsy w /proc albo /sys 30MB
> stalego zapisu to nie byle co i nawet na serwerze ktory robi za baze
> danych tyle zazwyczaj nie ma. Tam cos innego sie musialo dziac. Albo
> te numerki sa niepoprawne z jakiegos powodu. Albo inaczej: Moze nie
> masz pod linuxem ustawionego noatime? Wtedy kazdy odczyt powoduje
> malenki zapis. Bo access time trzeba dodac. Wtedy zapis tych 4 bajtow
> (czy ile tam ta data zajmie) spowoduje zapis calego bloku na ssd. I
> jak masz duzo odczytow to moze dojsc do sytuacji gdzie te 4bajty
> spuchna do 512 czy ile tam sektor na ssd teraz jest. a to jest jakies
> 100x wiecej...

Dzięki, popatrzę, ale obecnie nic się nie dzieje.

--
Marcin