eGospodarka.pl

eGospodarka.plGrupypl.comp.pecetinterpretacja zachowania dysku › Re: interpretacja zachowania dysku
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.man.poznan.pl!newsfeed.pionier.net
    .pl!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!n
    ewsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!new
    s.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!n
    ewsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!unt-spo-a-01.news.neostrada.p
    l!news.neostrada.pl.POSTED!not-for-mail
    From: a...@p...com
    Newsgroups: pl.comp.pecet
    Subject: Re: interpretacja zachowania dysku
    Date: Wed, 12 Jan 2022 03:02:41 +0100
    Message-ID: <u...@4...com>
    References: <HJbDJ.180161$onI5.83162@fx13.ams1>
    <a...@g...com>
    <2...@4...com>
    <4...@g...com>
    <GtpDJ.41446$Imt7.20696@fx09.ams1>
    X-Newsreader: Forte Agent 4.2/32.1118
    MIME-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: 8bit
    Lines: 62
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 83.5.252.214
    X-Trace: 1641952968 unt-rea-a-02.news.neostrada.pl 544 83.5.252.214:50558
    X-Complaints-To: a...@n...neostrada.pl
    X-Received-Bytes: 4377
    Xref: news-archive.icm.edu.pl pl.comp.pecet:1273421
    [ ukryj nagłówki ]

    Wcale nie przypadkiem, dnia Wed, 12 Jan 2022 00:42:14 GMT
    doszła do mnie wiadomość <GtpDJ.41446$Imt7.20696@fx09.ams1>
    od Marcin Debowski <a...@I...zoho.com> :
    >On 2022-01-11, ptoki <s...@g...com> wrote:
    >> wtorek, 11 stycznia 2022 o 11:46:55 UTC-6 a...@p...com napisał(a):
    >>> Wcale nie przypadkiem, dnia Tue, 11 Jan 2022 08:03:54 -0800 (PST)
    >>> doszła do mnie wiadomość
    >>> <a...@g...com>
    >>> od ptoki <s...@g...com> :
    >>> >wtorek, 11 stycznia 2022 o 03:03:38 UTC-6 Marcin Debowski napisał(a):
    >>>
    >>> >> Zapuściłem mu badblocks z zapisem i tu nastąpiło pierwsze WTF, bo
    >>> >> przeszedł bez błędów.
    >>> >>
    >>> >Jest tak jak ma byc.
    >>> >197 ci spadlo bo dysk sobie zrealokowal pending sectors.
    >>> >
    >>> No nie do końca, jak by zreallokował, to by wskoczyły do reallocated
    >>> sectors.
    >>> Do 197 trafiają sektory z błędnym odczytem danych(procedury wewnętrzne
    >>> nie potrafiły tego skorygować), jednak zapis do takiego sektora się
    >>> powiódł i sektor został na miejscu. Coś musiało spowodować taki błąd i
    >>> jest wielce prawdopodobne, że to się znowu stanie za jakiś czas,
    >>> loteria.
    >>
    >> No nie do konca.
    >> 197 to sektory czekajace na przemapowanie. One nie beda juz reuzyte. A
    przynajmniej nie w oficjalnej onterpretacji. Co se tam producent zrobil to inna
    inkszosc.
    >> Czyli po zapisie beda juz w innym miejscu. Wyzerowane 197 to znak ze dysk nie
    powinien juz miec bledow odczytu i tak sie stalo. To oczekiwana reakcja po
    badblocksach z zapisem.
    >>
    >> To ze sektory padaja to loteria ale nie znaczy ze ruszy lawina. Tak
    >> jak pisalem, mam pare dyskow ktore wg coponiektorych powinny znalezc
    >> sie w smieciach a dzialaja wesolo i bezproblemowo od lat.
    >
    >No właśnie to chyba mój pierwszy taki przypadek, że dysk mi się sypie
    >jakoś łagodnie. Zwykle idzie to lawinowo, lub od razu zdechł pies.
    >
    >Nb. odnosnie dyskusji, tam w zasadzie jest napisane
    >"Reallocated_Event_Count" a nie ilość bloków/sektorów. Nie wiemy
    >(wiemy?) jak to dysk liczy i co np. kończy takie zdarzenie. Więc te
    >Offline_Uncorrectable to może spokonie się mieścić w 2ch takich "event".
    >
    >Innymi słowy w zasadzie nic nie wiadomo poza tym, że coś się dzieje.

    Sprawa jest prosta, dysk ma dwie tabele reallokowanych sektorów,
    "fabryczne" - P-List i powstałe u usera końcowego G-List.
    Jeśli jakiś sektor zostanie reallokowany u usera, to musi trafić do
    G-List, nie ma w dyskach innej, "tajnej" tabeli na takie sektory,
    translator musi znać nowe adresy sektorów po podmianie.
    197 to sktory, które odczytują się z błędem i algorytm korekcji nie
    może tego błędu naprawić, mogą sobie tkwić w takim stanie do usranej
    znaczy się usłanej różami całkowitej śmierci dysku.
    Naprawa polega na zapisie do takiego sektora i weryfikacji, jak się
    zweryfikuje poprawnie, to sektor nie jest reallokowany, jak znów jest
    błąd, to sektor trafia do G-List w której też zapisywany jest adres
    sektora zamiennego.
    Takie sektory nie powstają bez powodu, ich obecność może świadczyć o
    kłopotach z nośnikiem czy innych problemach, dysk przestaje być
    "zaufany" i moim zdaniem powinien zostać objęty wcześniejszą
    emeryturą, ewentualnie można go stosować jako magazyn na mniej ważne
    dane.
    Victoria i MHDD dają sobie radę w naprawie takich sektorów bez
    ruszania reszty danych na dysku.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: