On 2020-10-14, pioruns <www@website.com> wrote:
> On 14/10/2020 00:26, Marcin Debowski wrote:
>> Nie mogę tam wleźć, bo str. uważa, że ją atakuję :)
>> A nie masz możliwość zakupu tech kości aby sprawdzić i jeśli nie działają,
>> zwrócić?
>
> Właśnie tak zrobiłem. Zakupiłem jedną kość 16GB 2666MHz DDR4 ECC CL19
> DIMM marki Kingston Server Premier:
> https://www.ebuyer.com/834676-kingston-server-premier-ksm26ed8-16me-16gb-2666mhz-ddr4-ecc-cl19-dimm-ksm26ed8-16me
>
> Zobaczymy jak przyjdzie, czy działa :)
Też jestem ciekaw :)
>> ECC są generalnie bardzo drogie. Chyba mimo wszystko próbowałbym to
>> jakoś ogarnąć programowo. Nie wiem, zrobić automatyczne tworzenie plików
>> par2 z bardzo niską redundancją (0.1-0.5%) z okresowym spradzaniem?
>
> A możesz przybliżyć co masz na myśli z tworzeniem tych plików, dokładniej?
Jakiś skrypt, który skanuje dyski, jeśli znajdzie nowy plik to zapuszcza
par2 i robi plik korekcyjny. Wczesniej oczywiście sprawdza czy ten już
nie istnieje. Jak potem stwierdzisz uszkodzenie to będzie łatwo
odtworzyć. Miejsca przy niskiej redundancji tez to nie zajmie.
> Wyczerpały mi się pomysły, dlatego wziąłem się za pamięć ECC, bo serwer
> chodzi 24/7, to fakt. A dane odnośnie statystycznej ilości bitów
> uszkodzonych na miesiąc na 1 GB zwykłego RAM mnie powalił. Dalej myślę,
> czy to czasem nie dyski, czy kontroler czy coś. Przykładowo, jeden z
> dysków raportuje się tak:
>
> Model Family: Seagate Barracuda 3.5
> Device Model: ST2000DM006-2DM164
> Serial Number: Z4Z9VCVN
> LU WWN Device Id: 5 000c50 0a5def0ef
> Firmware Version: CC26
> User Capacity: 2,000,398,934,016 bytes [2.00 TB]
> Sector Sizes: 512 bytes logical, 4096 bytes physical
> Rotation Rate: 7200 rpm
> Form Factor: 3.5 inches
> Device is: In smartctl database [for details use: -P show]
> ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b
> SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
>
> ID# ATTRIBUTE_NAME: RAW_VALUE
> 1 Raw_Read_Error_Rate: 125205888
> 7 Seek_Error_Rate: 1829851896660
E, chyba się zgubiłem, to powyższe nie wygląda jak prawie padły dysk?
Moja 1TB Toshiba 2.5" z 2x dłuższym godzinowo przebiegiem ma tu 2x 0.
Też pracuje w serwerze 24/7, ram zwykły.
> 9 Power_On_Hours: 14599
> 240 Head_Flying_Hours: 11119h+37m+20.737s
> 241 Total_LBAs_Written: 226553923475
> 242 Total_LBAs_Read: 464637728080
> Nie wiem jak czytać "Total_LBAs_Written" i "Total_LBAs_Read", ale jeśli
> przyjąć, że LBA to 512 bajtów, to dyski zapisują 36 TB na rok i czytają
> 283 TB na rok, po przeliczeniu ile pracowały. A mają po 2 TB pojemności.
> Gdyby to były SSD to już by się dawno zajechały, mam wrażenie :)
Przyjmując rozmiar sektora 512 powyższe oznacza że w ciągu 14599h
zapisano ca 100TB. Wychodzi ca 2.1MB/s. Przyjmując dalej, że
nieuśredniona prędkość zapisu była w granicach 70MB/s, oznacza to, że w
ciągu roku dysk zapisywał 12 dni więc te dane dla błędów RAMu należałoby
przemnożyć przez 12 i podzielić przez 365.
To tego jeszcze operacje dyskowe nie korzystają z pełnego RAM, a zapewne
z jakiejś niewielkiej jego częsci, więc to się też tak nie przekłada, że
czym masz więcej ramu, tym większe prawdopodobieństwo błędu na dysku a
jest to raczej proporcjonalne do statystycznej zajętości RAMu przez
jakiś dyskowy cache czy inny bufor wykorzystywany do zapisu. To są
pewnie dziesiątki-setki MB niż GB, więc i prawdopodobieństwo, że
dziabnie taki fragment jest pomniejszoneo dalszy rząd wielkości.
Czyli przy 1bit/miesiac/1GB wychodzi mi pi x drzwi, ze powinieneś mieć z
tego błędów na dysku w granicach 1 bit na 30 lat.
--
Marcin
|