🚀 go-pugleaf

On 19.04.2023 19:45, heby wrote:
> Muszę powiększyć dysk w NASie do ~8TB. NAS działa 24/dobę.
> 
> Ponieważ wydajność jest zupełnie nieistotna (byle wysycało 1Gbit/s), to 
> szukam czegoś powolnego, taniego.
> 
> Ale nie chciałbym wdepnąć w jakąs popsutą serię, któa padnie po tygodniu.
> 
> Może ktoś podrzucić, czym warto się zainteresować? Obecnie rozglądam się 
> za ST8000DM004, ale cały czas z tyłu głowy mi siedzi, że nawet jak pisza 
> "nowy", to to wydłubane z jakiegoś racka i skasowane liczniki. Strach 
> kupować :/

A może po prostu świadomie kupić UŻYWANE za tani piniondz? Np. tego rodzaju:

https://allegro.pl/oferta/dysk-twardy-hgst-800gb-8tb-sata-iii-3-5-7200-12827976428

Przynajmniej wiesz co kupujesz, jeśli nie ma błędów to dysk może jeszcze 
dekadę pochodzić, a z nowymi różnie bywa, czasem padnie tuż po gwarancji 
albo jeszcze na gwarancji sypnie reallocated sectors i nic nie 
poradzisz, bo gwara tego nie ogarnia.

-- 
pzdr
Roman

On 19/04/2023 20:58, Roman Tyczka wrote:
> A może po prostu świadomie kupić UŻYWANE za tani piniondz?

Nie wykluczam. W zasadzie obawiam się głównie tych, które padły i 
wyzerowano im liczniki.

Jak sprawny i nie kłamią o jego historii, to jak najbardziej.

Dzięki za linka.

On 19.04.2023 21:02, heby wrote:
> On 19/04/2023 20:58, Roman Tyczka wrote:
>> A może po prostu świadomie kupić UŻYWANE za tani piniondz?
> 
> Nie wykluczam. W zasadzie obawiam się głównie tych, które padły i 
> wyzerowano im liczniki.
> 
> Jak sprawny i nie kłamią o jego historii, to jak najbardziej.
> 
> Dzięki za linka.

Pytałem jednego typa (nie tego z linka) o przebiegi i mi napisał, że 
40k-60k (więc nie zerują), czyli jakieś 5 lat jazdy... dla HDD to nie 
jest jakiś zabójczy czas... no chyba, że orał głowicami non stop przez 
te 5 lat, ale jak sobie wyobrażam jakieś hostingi to tam cache zgarnia 
80% ruchu i te dyski de facto aż takiej orki nie mają... mogę się 
oczywiście srogo mylić. Ale cena zachęca do ryzyka :-)

-- 
pzdr
Roman

On 19.04.2023 21:02, heby wrote:
>> A może po prostu świadomie kupić UŻYWANE za tani piniondz?
> 
> Nie wykluczam. W zasadzie obawiam się głównie tych, które padły i 
> wyzerowano im liczniki.
> 
> Jak sprawny i nie kłamią o jego historii, to jak najbardziej.
> 
> Dzięki za linka.

Planujesz zakup tego dysku? Bo ja będę chciał docelowo 3 sztuki do raida 
kupić, więc jak coś będziesz wiedział napisz pliz o nim. Ewentualnie 
możemy kupić po jednym u dwóch sprzedawców i porównać liczniki, jak 
będzie gdzieś brzydko to odeśle się w 14 dni.

-- 
pzdr
Roman

środa, 19 kwietnia 2023 o 12:45:50 UTC-5 heby napisał(a):
> Cześć. 
> 
> Muszę powiększyć dysk w NASie do ~8TB. NAS działa 24/dobę. 
> 
> Ponieważ wydajność jest zupełnie nieistotna (byle wysycało 1Gbit/s), to 
> szukam czegoś powolnego, taniego. 
> 
> Ale nie chciałbym wdepnąć w jakąs popsutą serię, któa padnie po tygodniu. 
> 
> Może ktoś podrzucić, czym warto się zainteresować? Obecnie rozglądam się 
> za ST8000DM004, ale cały czas z tyłu głowy mi siedzi, że nawet jak pisza 
> "nowy", to to wydłubane z jakiegoś racka i skasowane liczniki. Strach 
> kupować :/


Ogolnie to w takich tematach warto zajrzec na raporty backblaze.
Oni kupuja konsumerowe dyski i maja z nich potem statsy awaryjnosci.
Nie zawsze dana seria jest u nich na stanie ale jak maja felerne modele to wiadomo czego unikac.

Jakis czas temy shitgate mial bardzo slaba serie 2-3TB. Szybko padaly.

Teraz ogolnie nie jest u nich zle ale ja unikam jak moge. Biore WD/toshiba ewentualnie szajsungi.

W praktyce jak masz dobrze ogarniete kopie zapasowe to kup cokolwiek. Byle gwarancja byla albo cena taka zeby nie martwic sie jak padnie.
Ale trzeba miec te replikacje postawiona i jakos ja uskuteczniac.

On 21/04/2023 17:02, ptoki (ptoki) wrote:
> Ale trzeba miec te replikacje postawiona i jakos ja uskuteczniac.

Mam automatyzację w postaci przypomnienia w kalendarzu :)

piątek, 21 kwietnia 2023 o 10:56:13 UTC-5 heby napisał(a):
> On 21/04/2023 17:02, ptoki (ptoki) wrote: 
> > Ale trzeba miec te replikacje postawiona i jakos ja uskuteczniac.
> Mam automatyzację w postaci przypomnienia w kalendarzu :)

Ten kalendarz sprawia ze rece ci to robia albo tylko przypomina?

Sugeruje ogarnac sobie jakiegos rsynca na inne dyski. Wybrane katalogi starcza, z tym co wazne, jak masz filmy czy mp3 z internetu to mozesz olac. Ale swoje dokumenty syncuj gdzies.

Niezaleznie czy kupisz tani czy dobry dysk. syncuj.

On 21/04/2023 21:00, ptoki (ptoki) wrote:
> Ten kalendarz sprawia ze rece ci to robia albo tylko przypomina?

Fizyczną pracę wykonuje białko.

> Sugeruje ogarnac sobie jakiegos rsynca na inne dyski.

Mam coś takiego.

Ale:
1) To wymaga komputera w innej lokalizacji (na wypadek jakiejś 
katastrofy w zasilaniu, typu 400V na fazie). Mam, ale na za wolnym łaczu 
aby to było efektywne jako ciągły proces w tle.

2) Stosuje również nośnik offline.

3) 2 jeszcze nie wkładam do klatki Faradaya, ale kto wie ;)

Co do 1) to być może ogarniemy z kolegą wymianę się dyskami, ja mu włożę 
jego, on mój do swojej sieci i będziemy mieli jakiś backup odporny na 
katastrofy.

W sumie kiedyś dawno czytałem, że jest jakiś serwis synchronizujący 
hobbystów w usa, zapewniajacych sobie wzajemnie backupy, taka 
niby-chmura zanim to jeszcze było modne. Nie wiem jak się to nazywa i 
nie wiem czy ktoś tego używa(ł) u nas....

On 21/04/2023 15:16, heby wrote:
>> Dysk ma w smarcie kilka błedów DMA
> A, i ~50k godzin.

I wszystko jasne, po zapianiu 8TB zer:

1) prędkość spada z 200MB do 160MB pod koniec
2) statu smart, poza wzrostem ilosci godzin pracy, nie ma ani śladu różnicy
3) błedy DMA sa dokładnie takie same jak były
4) podczas pracy słychać miarowe cyknięcia głowicy, prawie jak floppy w 
Amidze. Nie wiem czy to część normalnej pracy, czy efekt relokowanych 
sektorów z zapasu. Ale coś zbyt równo to działa, co 2 sek, wiec zakładam 
że część poprawnie działajacego algorytmu.

Chyba sprawny.

piątek, 21 kwietnia 2023 o 15:31:56 UTC-5 heby napisał(a):
> On 21/04/2023 21:00, ptoki (ptoki) wrote: 
> > Ten kalendarz sprawia ze rece ci to robia albo tylko przypomina?
> Fizyczną pracę wykonuje białko.
> > Sugeruje ogarnac sobie jakiegos rsynca na inne dyski.
> Mam coś takiego. 
> 
> Ale: 
> 1) To wymaga komputera w innej lokalizacji (na wypadek jakiejś 
> katastrofy w zasilaniu, typu 400V na fazie). Mam, ale na za wolnym łaczu 
> aby to było efektywne jako ciągły proces w tle. 
> 

Niekoniecznie

> 2) Stosuje również nośnik offline. 
> 

Tak, do dobra droga, nie idealna ale jak sie robi rsynca na drugi dysk co pare dni to nie jest to zle rozwiazanie.

> 3) 2 jeszcze nie wkładam do klatki Faradaya, ale kto wie ;) 
> 

Mozna byc paranoikiem ale czasem nie warto.
Ten oflineowy dysk sobie zdybluj i wynos gdzies indziej. 
Warto go zaszyfrowac bo nie wiadomo kto go ukradnie.

> Co do 1) to być może ogarniemy z kolegą wymianę się dyskami, ja mu włożę 
> jego, on mój do swojej sieci i będziemy mieli jakiś backup odporny na 
> katastrofy. 
> 

Z jednej strony tak z drugiej nie, bo jak on se pogrzebie w kompie zle  i ci dyska skasuje to kiszka. 
Ale generalnie to zalezy od okolicznosci.

> W sumie kiedyś dawno czytałem, że jest jakiś serwis synchronizujący 
> hobbystów w usa, zapewniajacych sobie wzajemnie backupy, taka 
> niby-chmura zanim to jeszcze było modne. Nie wiem jak się to nazywa i 
> nie wiem czy ktoś tego używa(ł) u nas....

IMHO przerost tresci nad forma. Tzw metoda google czyli kopia na trzech nosnikach jest calkiem ok.

On 22.04.2023 00:42, heby wrote:
> On 21/04/2023 15:16, heby wrote:
>>> Dysk ma w smarcie kilka błedów DMA
>> A, i ~50k godzin.
> 
> I wszystko jasne, po zapianiu 8TB zer:
> 
> 1) prędkość spada z 200MB do 160MB pod koniec
> 2) statu smart, poza wzrostem ilosci godzin pracy, nie ma ani śladu różnicy
> 3) błedy DMA sa dokładnie takie same jak były
> 4) podczas pracy słychać miarowe cyknięcia głowicy, prawie jak floppy w 
> Amidze. Nie wiem czy to część normalnej pracy, czy efekt relokowanych 
> sektorów z zapasu. Ale coś zbyt równo to działa, co 2 sek, wiec zakładam 
> że część poprawnie działajacego algorytmu.
> 
> Chyba sprawny.

Widzę tylko ten ostatni post, który jest odpowiedzią na Twój poprzedni 
post, którego ...nie ma, na dwóch serwerach na jakich mam grupy 
skonfigurowane. Wrzuć go jeszcze raz pliz.
I dzięki za info.


-- 
pzdr
Roman

On 22/04/2023 10:07, Roman Tyczka wrote:
> Widzę tylko ten ostatni post, który jest odpowiedzią na Twój poprzedni 
> post, którego ...nie ma, na dwóch serwerach na jakich mam grupy 
> skonfigurowane. Wrzuć go jeszcze raz pliz.

On 21/04/2023 14:48, Roman Tyczka wrote:
 > Planujesz zakup tego dysku?

Już kupiłem i właśnie oram trzeci TB za pomocą dd if=/dev/zero z 
jednoczesnym zapisaniem raportu smarta przed i po (aby zobaczyć, co się 
zmieniło). Powinno do jutra zakończyć (200MB/sek zapis :/).

Dysk ma w smarcie kilka błedów DMA, ale co z tego można wywnioskować - 
nie wiem. Wiele moich dysków ma takie błedy i nigdzie się nie wybierają.

Ma też testy, ale tutaj zaskoczenie: test typu "long" trwa minutę, 
strasznie hałasuje głowicą i faktycznie kończy się po tej 1 minucie z 
"success".

On 22.04.2023 11:19, heby wrote:

> Już kupiłem i właśnie oram trzeci TB za pomocą dd if=/dev/zero z 
> jednoczesnym zapisaniem raportu smarta przed i po (aby zobaczyć, co się 
> zmieniło). Powinno do jutra zakończyć (200MB/sek zapis :/).
> 
> Dysk ma w smarcie kilka błedów DMA, ale co z tego można wywnioskować - 
> nie wiem. Wiele moich dysków ma takie błedy i nigdzie się nie wybierają.
> 
> Ma też testy, ale tutaj zaskoczenie: test typu "long" trwa minutę, 
> strasznie hałasuje głowicą i faktycznie kończy się po tej 1 minucie z 
> "success".

Dzięki. To jeszcze dopytam jak z hałasem ogólnym dysku? Terkocze tak, że 
zwraca to uwagę czy da się zignorować? No i jaki model konkretnie kupiłeś?

-- 
pzdr
Roman

On 23/04/2023 14:42, Roman Tyczka wrote:
> Dzięki. To jeszcze dopytam jak z hałasem ogólnym dysku?

Praca silnika niesłyszalna, ale ja niekoniecznie jestem audiofilem. 
Musiałem oceniać, czy się kręci, dotykając obudowy.

> Terkocze tak, że 
> zwraca to uwagę czy da się zignorować?

Terkotanie głowic słyszalne przy otwartej obudowie. Trudno mi ocenić, 
czy więcej/mniej od typowego hałasu z innych dysków. Wydaje mi się, że w 
normie. Natomiast uruchomienie testu powoduje dość głośny hałas, wiec 
teoretycznie dysk jest zdolny do wydawania głośnych dzwięków. 
Przerzuciłem tam kilka tb plików w te i nazad i tak głośno, jak podczas 
testu, nie pracuje. Nazwałbym go zupełnie normalnym pod wzgledem hałasu 
dyskiem, jaki kilka moich innych.

> No i jaki model konkretnie kupiłeś?

Ten ze zlinkowanej aukcji.

HUH728080ALE601

https://drive.google.com/file/d/15AhxUyfqlq7K1k2qFSNR8Q4nN2w1IBss

W dniu 22.04.2023 o 08:39, ptoki (ptoki) pisze:
> IMHO przerost tresci nad forma. Tzw metoda google czyli kopia na trzech nosnikach jest calkiem ok.

zależy gdzie te nośniki, bo jak się dom spali czy jakaś powódź będzie to słabo, albo nie 
daj boże zwykły piorun kiedy akurat wszystkie trzy będą online

a tak - hostujesz komuś jakiś zaszyfrowany kontener, a w zamian dostajesz takie samo 
miejsce pół kraju czy świata dalej - ciekawa opcja

Deep inside the Matrix, convinced that Sun, 23 Apr 2023 17:00:54 +0200
is the real date, heby <heby@poczta.onet.pl> has written something
quite wise. But (s)he wasn`t the one.

>> No i jaki model konkretnie kupiłeś?
>
>Ten ze zlinkowanej aukcji.
>
>HUH728080ALE601
>
>https://drive.google.com/file/d/15AhxUyfqlq7K1k2qFSNR8Q4nN2w1IBss

Minęły dwa tygodnie, może follow-up? Jakieś nowe uwagi, czy wszystko w
porządku, nudy, nic się nie dzieje?
Jestem ciekaw, bo korci mnie te 8TB, ale cena za używany dysk jest
znacząco wyższa od tych które jestem przyzwyczajony płacić, muszę
jakoś przekonać węża księgowego :)

Pozdrawiam!

On 10/05/2023 12:54, mordazy@somewherefaraway.com wrote:
>> https://drive.google.com/file/d/15AhxUyfqlq7K1k2qFSNR8Q4nN2w1IBss
> Minęły dwa tygodnie, może follow-up?

Z tych 2 tyg, 1 tydzień byłem poza domem.

Dysk przez ten czas sobie pracuje "jałowo" albo robiąc za leniwego NASa 
(w sumie to zdążyłem przerzucić tylko na niego dane).

Nic się nie dzieje.

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.

On Wednesday, May 10, 2023 at 6:17:01 a.m. UTC-5, heby wrote:
> On 10/05/2023 12:54, mor...@somewherefaraway.com wrote: 
> >> https://drive.google.com/file/d/15AhxUyfqlq7K1k2qFSNR8Q4nN2w1IBss 
> > Minęły dwa tygodnie, może follow-up?
> Z tych 2 tyg, 1 tydzień byłem poza domem. 
> 
> Dysk przez ten czas sobie pracuje "jałowo" albo robiąc za leniwego NASa 
> (w sumie to zdążyłem przerzucić tylko na niego dane). 
> 
> Nic się nie dzieje. 
> 
> 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.

On Tuesday, May 9, 2023 at 4:49:14 p.m. UTC-5, m4rkiz wrote:
> W dniu 22.04.2023 o 08:39, ptoki (ptoki) pisze:
> > IMHO przerost tresci nad forma. Tzw metoda google czyli kopia na trzech nosnikach jest calkiem ok.
> zależy gdzie te nośniki, bo jak się dom spali czy jakaś powódź będzie to słabo, albo nie 
> daj boże zwykły piorun kiedy akurat wszystkie trzy będą online 
> 

Tak to nawet awsowe dziewiatki wysiadaja bo opisujesz skrajne przypadki.

> a tak - hostujesz komuś jakiś zaszyfrowany kontener, a w zamian dostajesz takie samo 
> miejsce pół kraju czy świata dalej - ciekawa opcja

Ta, i sciagnac sobie to spowrotem trwa godziny. 

Jako trzecia kopia to nie widze problemu ale dwie pierwsze warto miec gdzies pod reka. 

Ale jak tam wujenka sobie zyczy, my tu tylko sobie doradzamy wiec nie ma co ambicjonalnie podchodzic. Ja jade na trzech kopiach u siebie , jak mi sie dom spali to najmniej bede plakac za danymi z dyskow...

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 ;)

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

On 11/05/2023 18:40, ptoki (ptoki) wrote:
>> 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.

No wiec własnie po to patrzę w smarta - aby znaleźć *rosnącą* ilość 
relokacji podczas zapisu dd.

On Thursday, May 11, 2023 at 12:25:10 p.m. UTC-5, heby wrote:
> On 11/05/2023 18:40, ptoki (ptoki) wrote: 
> >> 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.
> No wiec własnie po to patrzę w smarta - aby znaleźć *rosnącą* ilość 
> relokacji podczas zapisu dd.

ah no to git.