czwartek, 10 listopada 2022 o 06:11:41 UTC-6 Marcin Debowski napisał(a):
> On 2022-11-10, Roman Tyczka <r...@h...you.spammer> wrote:
> > On 10.11.2022 11:24, Marcin Debowski wrote:
> >> On 2022-11-10, Roman Tyczka <r...@h...you.spammer> wrote:
> >>> On 10.11.2022 07:59, Marcin Debowski wrote:
> >>>> Device Boot Start End Sectors Size Id Type
> >>>> /dev/sda1 2048 8390655 8388608 4G 82 Linux swap / Solaris
> >>>> /dev/sda2 * 8390656 125045423 116654768 55.6G 83 Linux
> >>>> /dev/sda3 125046784 488397167 363350384 173.3G 83 Linux
> >>>>
> >>>> Widać, że swoje już odsłużył, pada, ale ciekawi mnie taka rzecz:
> >>>> Ostatnia partycja nie była w ogóle w użyciu, a teraz jak ją przemiatam
> >>>> badblockiem to równeż sypie błędami odczytu. Dlaczego?
> >>>
> >>> Bo kontroler rozrzuca dane po całym fizycznym dysku?
> >>> Dlatego zaleca się zostawienie 10% niespartycjonowanej powierzchni na
> >>> SSD, wtedy nawet dobicie zajętością do 100% pozostałych partycji nie
> >>> jest groźne.
> >>
> >> Skąd kontroler wie jak jest spartycjowany dysk? To nie ten MZ poziom
> >> abstrakcji. Partycje nie są inicjowane poprzez wypełnienie ich w
> >> jakikolwiek sposób a typów partycji jest kilka.
> >
> > No właśnie nie wie, bo nie musi wiedzieć. Wie, ża ma blok danych zapisać
> > na dysku i zapisuje tam gdzie chce, mając partycje w nosie.
> To nie rozumiem komentarza, że się zaleca min 10% skoro z tego co
> napisałem wynika, że zostawiłem wolne jakieś 70%. Pytanie, dlaczego te
> 70% ma błędy skoro nic tam zasadniczo nie pisało. Obstawiam, że może

1. Minimum 10% oznacza minimum. 30% jest lepiej ale nadal ten problem wystepuje.
2. Musisz wiedziec ze kontroler sledzi caly dysk i liczy sobie jak mocno uzyte sa
poszczegolne bloki komorek.
3. Uzycie tych blokow jest zazwyczaj bardzo nierownomierne.
4. Sa sposoby aby dac mu troche zycia.

> mieć to coś wspólnego z faktem, że pojedyncza komórka mieści tu, zdaje
> się 2 bity i może jak jedna warstwa pójdzie się paść to ta druga, nawet
> nie używana, również. Ale tak se spekuluje bo się nie znam.
>
> Dla porządku zwracam też uwagę, że ten dysk ma gwarancje na 150TWB a smart
> pokazuje, że zaliczył 3500TWB.
>
5. Nie jestem pewien czy dobrze policzyles ale to detal.

6 - najistotniejsze dla ciebie: Dla przykladu. Masz dyska z 100 komorkami. Kazda ma
10 zapisow zywotnosci. Czyli tak jakby 100*10=1000 zapisow. I teraz dwa warianty:
1. Zapisujesz caly dysk raz i tracisz 10% jego zywotnosci - 100zapisow. Kasujesz
wszystko, dajesz dyskowi znac zeby wykonal trim, on sie orientuje ze nadal ma 9
zapisow na kazdej komorce. Zapisujesz ponownie caly i masz 20% zuzycia. W ten sposob
uzyskasz 1000 zapisow i dysk padnie*
2. Zapisujesz caly dysk w 70%. Zuzyles 7% jego trwalosci. Ale teraz piszesz ciagle te
30% pojemnosci i po 300 zapisach dysk zdycha. Dlaczego? Bo zapisywales te same
przestrzenie wiele razy I mimo ze TBW jest/moze byc nieduze to kazda komorka z tych
30% zostanie zapisana wielokrotnie wiecej.

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.

* - pad dysku jest dosyc nierownomierny. Kontroler sobie sprawdza jakiej jakosci sa
komorki i moze czasem stwierdzic ze nie ma co, padamy na sztywno i szybko a czasem
probuje cos z tym zrobic i pada podobnie jak pokazujesz. Kiedys padaly na zimno i nie
bylo nawet bledow odczytu. Jak sie pojawily to dysk potem juz w biosie sie nawet nie
pokazywal. Teraz widze ze jest nieco lepiej.

ad4. Jak skasujesz wszystko z dysku to mozesz miec szczescie i jeszcze nieco danych
zapiszesz zanim padnie. Kontroler moze zaczac chetniej uzywac komorki mniej zuzyte
(zakladamy ze te 30% teraz jest mocno zuzyte a te 70% tylko czesciowo i powiedzmy 50%
tych 70% jest zapisane tylko pare razy) wiec jakbys zmniejszyl te partycje do
powiedzmy (z dupy estymacja) do 100GB to ten dysk nadal podziala.
Ale trzeba zrobic pelnego trim-a. Ja tak robi pod linuksem. Wysyla sie dyskowi info
zeby trimowal wszystkie bloki i on ma szanse zaczac uzywac te co sa najmniej zuzyte.

Ale feler jest taki ze jak przekroczysz bariere (ilosciowa) za ktora sa zuzyte bloki
i je zaczniesz ponownie nadpisywac (jakies logi czy baza danych) to dysk padnie na
twardo.

To tak zgrubsza. Mysle ze nieco wyjasnia sytuacje.