Article View: pl.comp.pecet
Article #1273145Re: Tani 8TB na archiwum
From: ptoki (ptoki)
Date: Thu, 11 May 2023 16:40
Date: Thu, 11 May 2023 16:40
37 lines
5103 bytes
5103 bytes
On Thursday, May 11, 2023 at 3:50:57 a.m. UTC-5, heby wrote: > On 11/05/2023 05:00, ptoki (ptoki) wrote: > >> Będę puszczał jeszcze jakieś testy w postaci dd if=/dev/urandom > >> of=temp.bin na wolną przestrzeń i zobaczymy, czy rośnie coś po stronie > >> smarta. > > zeby roslo musisz czytac. > > zeby spadalo trzeba zapisac. > W sensie, że zapis powoduje spadek ilosci badblocków ;)? Tej sztuczki > nie znałem ;) Tak dziala to tak ze zdrowy sektor/blok/czy jak se to tam nazwiesz daje sie czytac bez problemu. Jak jakosc odczytu spada - kontroler sobie analizuje czy sygnal z glowicy jest czysty czy "zaszumiony" albo brakuje w nim czytelnych bitow to inicjalnie podaje dane bez ostrzezenia ale sobie zapamietuje dany blok jako niestabilny. Po przekroczeniu progu akceptowalnosci jakosci odczytu zaznacza go do relokacji. Nie znam dyskow co same relokuja sektory. Moze takie sa ale zazwyczaj taka degradacja dla usera jest niewidoczna poza zajrzeniem w smarta. A i wtedy nie jest prosto dostac liste tych sektorow i zamapowac na plik. Niby sie da bo gdzies tam ten sektor jest i mozna narzedziamu sprawdzic ktory plik go okupuje ale to nieco dlubanina i zalezy od systemu plikow, rozkladu partycji itp. Przy jakims LVM to wogole trudniej itp... Normalnie taki stan z niestabilnym odczytem sie utrzymuje az albo plik przestanie sie czytac - wtedy user sie wkurza albo jak user nadpisze ten sektor bo przekopiowal plik albo go nadpisal czyms innym. W takim momencie kontroler nie nadpisuje takiego oznaczonego sektora tylko zaznacza go jako zrelokowany i zapisuje se go gdzies indziej, pamietajac gdzie on oryginalnie byl. Wiec jak chcesz przetestowac dyska to czytasz. Bo bez czytania smartowa liczba sektorow do zrelokowania sie nie zmieni. To powoduje ze obszary dysku ktory wygladal na zdrowy przed takim skanem sa czytane i odkrywa sie ze jednak niektore sektory sa slabe. Niektorzy mysla ze ktos ich oszukal bo wyzerowal smart-a a jak zrobili skan to sie pokazaly bledy i mysl sie pojawia ze nie bylo ale sa to znaczy ze pewnie byly ale ktos wyzerowal. Wiec podczas skanu kontroler znajdzie takie slabe ale ich nie zrelokuje. Zeby liczba sektorow do zrelokowania spadla to trza je zrelokowac. Czyli zapisac ponownie. I wtedy liczba tych bad sektorow jak niektorzy mowia spada ale podnosi sie tych zrelokowanych. I tu niektorzy narzekaja ze maja dysk z duza iloscia takich relokacji i znowu, ze ktos im barachlo sprzedal. I to moze ale nie musi byc prawda. Fabrycznie takie dyski sa puszczane raz czy dwa razy na skanowanie (to trwa dlugo wiec czasem producent po prostu zaznacza zeby sie zrobilo juz u klienta i jak dysk bedzie pasciak to sie mu wymieni na gwarancji) i wtedy jak klient sobie zacznie dane zapisywac to sie od razu pewna ilosc sektorow zrelokuje. Zeby ocenic czy dysk jest dobry trzeba sledzic ilosc pending for relocation okazjonalnie skanujac cala powierzchnie i zrelokowac (tu jest trudniej) jak liczba wzrosla. W praktyce te liczby zmieniaja sie o niewiele. 10-50-100-1000 sektorow. Jak chcesz dbac o dyska to pusc mu smart test full w tle albo raz na miesiac skan calej powierzchni i sprawdz wynik smarta. Wiecej dlubac imho nie ma sensu. Jak masz backupy to starczy i nie trzeba wiele wiecej cudowac
Technical Details
Message-ID:
<23e1781c-f713-4c15-bb9b-b90ac778e4ebn@googlegroups.com>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!news.samoylyk.net!weretis.net!feeder6.news.weretis.net!news.misty.com!border-2.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mailReferences:
<u1p9cb$4m56$1@dont-email.me> <644039db$0$2966$65785112@news.neostrada.pl> <u1pdro$5dbi$1@dont-email.me> <64428638$0$2963$65785112@news.neostrada.pl> <u1u299$232mg$1@dont-email.me> <u1u2c0$232mg$2@dont-email.me> <u1v3h7$2u6d5$1@dont-email.me> <644395a9$0$19601$65785112@news.neostrada.pl> <u208rm$37d98$1@dont-email.me> <644527b9$0$2967$65785112@news.neostrada.pl> <u23h7e$3risu$1@dont-email.me> <r5tm5idaf9v8eq0lbk1jto804035322m7q@4ax.com> <u3fuf9$lq1i$1@dont-email.me> <8b61403d-0457-41b5-aac4-96f8489b25e4n@googlegroups.com> <u3ia9d$11qge$3@dont-email.me>Show Full Headers
Complete Article Headers
X-Received: by 2002:a05:620a:1790:b0:74f:693a:d48e with SMTP id ay16-20020a05620a179000b0074f693ad48emr7691397qkb.11.1683823234556; Thu, 11 May 2023 09:40:34 -0700 (PDT) X-Received: by 2002:a25:6b43:0:b0:b92:1f3c:a212 with SMTP id o3-20020a256b43000000b00b921f3ca212mr13418874ybm.8.1683823234009; Thu, 11 May 2023 09:40:34 -0700 (PDT) Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!news.samoylyk.net!weretis.net!feeder6.news.weretis.net!news.misty.com!border-2.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: pl.comp.pecet Date: Thu, 11 May 2023 09:40:33 -0700 (PDT) In-Reply-To: <u3ia9d$11qge$3@dont-email.me> Injection-Info: google-groups.googlegroups.com; posting-host=24.77.110.106; posting-account=jnRHMAoAAACB5EawItMhNTZMy_yOF2XE NNTP-Posting-Host: 24.77.110.106 References: <u1p9cb$4m56$1@dont-email.me> <644039db$0$2966$65785112@news.neostrada.pl> <u1pdro$5dbi$1@dont-email.me> <64428638$0$2963$65785112@news.neostrada.pl> <u1u299$232mg$1@dont-email.me> <u1u2c0$232mg$2@dont-email.me> <u1v3h7$2u6d5$1@dont-email.me> <644395a9$0$19601$65785112@news.neostrada.pl> <u208rm$37d98$1@dont-email.me> <644527b9$0$2967$65785112@news.neostrada.pl> <u23h7e$3risu$1@dont-email.me> <r5tm5idaf9v8eq0lbk1jto804035322m7q@4ax.com> <u3fuf9$lq1i$1@dont-email.me> <8b61403d-0457-41b5-aac4-96f8489b25e4n@googlegroups.com> <u3ia9d$11qge$3@dont-email.me> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <23e1781c-f713-4c15-bb9b-b90ac778e4ebn@googlegroups.com> Subject: Re: Tani 8TB na archiwum From: "ptoki (ptoki)" <sczygiel@gmail.com> Injection-Date: Thu, 11 May 2023 16:40:34 +0000 Lines: 68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit