"HF5BS" <h...@...pl> writes:

> Po prostu pech - dyskietki dziabnięte w tym samym miejscu każda. To
> prawda, że paproch potrafi zaszkodzić, potrafił błyskawicznie
> zeszlifować warstwę magnetyczną nośnika, do gołego mylaru, czyniąc
> dyskietkę bezużyteczną, bo jak się posypało, to zaczął się kruszyć na
> potęgę i nadawał sie tylko na fajans.

Dyskietki były bardzo zawodne (w szczególności 1.44 MB (3.5"), ze
względu na dużą gęstość zapisu - 2.8 MB nie używałem). Wydaje mi się, że
firmowe dyskietki były "nieco mniej złe", ale nawet te miały chwilami
pewność zapisu (prawdopodobieństwo, że wszystkie sektory dadzą się
odczytać) na poziomie 50% :-)
Pewnie zależało to także od napędów. Tak czy owak, w tej sytuacji,
szansa że 3 dyskietki nie dadzą się odczytać w konkretnym miejscu, wciąż
była dość duża.

Dyski twarde to zupełnie inna bajka, utrata danych z RAID-1 i RAID-5
(związana z uszkodzeniem dysków) zdarza się raz na ileś lat, przy RAID-6
lub RAID1+1 itp. w ogóle praktycznie się nie zdarza (pomijając
np. awarię zasilania, przepięcia, przegrzania itp. - które niszczą
wiele dysków jednocześnie).
Oczywiście nie należy zapominać, że istotne dane powinny być gdzieś
zduplikowane, w taki sposób, by odpowiednio trudno było je zniszczyć
jednocześnie z oryginałem.
--
Krzysztof Hałasa

do góry

Użytkownik "Krzysztof Halasa" <k...@p...waw.pl> napisał w wiadomości
news:m3val1s427.fsf@pm.waw.pl...
> Dyskietki były bardzo zawodne (w szczególności 1.44 MB (3.5"), ze
> względu na dużą gęstość zapisu - 2.8 MB nie używałem). Wydaje mi się, że
> firmowe dyskietki były "nieco mniej złe", ale nawet te miały chwilami
> pewność zapisu (prawdopodobieństwo, że wszystkie sektory dadzą się
> odczytać) na poziomie 50% :-)

Szybko się zdzierały.

> Pewnie zależało to także od napędów. Tak czy owak, w tej sytuacji,

Na moje oko bardzo. Byle paproch się przyklei przyz głowicy i potrafi
zrujnować nośnik.
Złapie wilgoci, to nośnik zacznie się kleić i odrywać.

> szansa że 3 dyskietki nie dadzą się odczytać w konkretnym miejscu, wciąż
> była dość duża.

Ano. Choć myślę, że to nie jedyny czynnik.

>
> Dyski twarde to zupełnie inna bajka, utrata danych z RAID-1 i RAID-5
> (związana z uszkodzeniem dysków) zdarza się raz na ileś lat, przy RAID-6
> lub RAID1+1 itp. w ogóle praktycznie się nie zdarza (pomijając
> np. awarię zasilania, przepięcia, przegrzania itp. - które niszczą
> wiele dysków jednocześnie).

Wiadomo, w końcu też serwerowe dyski wyróżniają sie (chyba...) trwałością,
kosztem bodajże nieco wolniejszej pracy. Zresztą i tak duża macierz... to
czy system zdoła przerobić taką ilość danych, by musiał czekać na kolejną
porcję? Ale w sensie przepływności przez pamięć...

> Oczywiście nie należy zapominać, że istotne dane powinny być gdzieś
> zduplikowane, w taki sposób, by odpowiednio trudno było je zniszczyć
> jednocześnie z oryginałem.

Otóż to!
Dlatego ówe dane, to u mnie sobie leżały, bo się liczyłem, że przeniesienie
może się nie udać.

Robię teraz dysk, któremu się fiknęło z wysokości...
Sczytanie upadłego dysku (udało się tylko raz, przy drugim czytaniu - dla
upewnienia się w odzysku - umarł) zrobiłem tak, że najpierw obraz, potem
wyciągnięcie danych, teraz je porządkuję, dla pewności ponownie procedura
(aby upewnić się, że błąd pamięci nie namieszał, uszkodzony moduł usunąłem,
sczytać chyba udało się dobrze (w ocenie oparłem się, tak, o coś, co można
by nazwać głosowaniem)) wyciągania danych z obrazu (drugiego nie ma i nie
będzie), przekazanie odzysku i po sygnale, że wszystko gra, dopiero
wyczyszczenie miejsca.
Nieraz widziałem sytuacje, z podziału na ludzi robiących backupy, oraz
tych, co będą je robić. Sam do tych drugich należałem... :)
Niektóre programy potrafią zapisywać dwoje dane w kilku miejscach naraz,
wolę to od sytuacji, gdyby coś miało się zgubić.

--
Psy kochają przyjaciół i gryzą wrogów,
w odróżnieniu od ludzi, którzy niezdolni są do czystej miłości
i zawsze muszą mieszać miłość z nienawiścią.
(C) Zygmunt Freud.

do góry

"HF5BS" <h...@...pl> writes:

> Wiadomo, w końcu też serwerowe dyski wyróżniają sie (chyba...)
> trwałością, kosztem bodajże nieco wolniejszej pracy.

Podobno tak. Chociaż RAID, jak sama nazwa wskazuje ("inexpensive"),
nie wymaga drogich dysków. Lepiej tańsze (i szybsze), ale więcej.

> Zresztą i tak
> duża macierz... to czy system zdoła przerobić taką ilość danych, by
> musiał czekać na kolejną porcję? Ale w sensie przepływności przez
> pamięć...

Bez mrugnięcia okiem.
Typowa pamięć DDR3 (lub DDR4), dziesiątki GB/s. Dysk to ~ 100 MB/s
liniowego transferu, albo co ważniejsze 100-200 IO/s. Nawet szybki SSD
jest znacznie wolniejszy od typowego zestawu DRAM.

Aczkolwiek możliwe są konfiguracje patologiczne - np. wolne mosty
południowe - w przeszłości to była pięta achillesowa, zwłaszcza typowych
desktopowych inteli (wolna szyna DMI - nowe Intele praktycznie dogoniły
już pod tym względem Athlona 64 z 2004 r). Z tym, że problem ujawniał
się tylko w zastosowaniach używających szybkich liniowych transferów,
np. związanych z obróbką video.
--
Krzysztof Hałasa

do góry

Użytkownik "HF5BS" napisał w wiadomości grup
dyskusyjnych:ooejrn$96t$...@n...news.atman.pl...
Użytkownik "Krzysztof Halasa" <k...@p...waw.pl> napisał w wiadomości
>> Dyskietki były bardzo zawodne (w szczególności 1.44 MB (3.5"), ze
>> względu na dużą gęstość zapisu - 2.8 MB nie używałem). Wydaje mi
>> się, że
>> firmowe dyskietki były "nieco mniej złe", ale nawet te miały
>> chwilami
>> pewność zapisu (prawdopodobieństwo, że wszystkie sektory dadzą się
>> odczytać) na poziomie 50% :-)
>Szybko się zdzierały.

Az tylu bledow nie mialem, ale tez niewiele ich uzywalem.

>> Pewnie zależało to także od napędów. Tak czy owak, w tej sytuacji,
>Na moje oko bardzo. Byle paproch się przyklei przyz głowicy i potrafi
>zrujnować nośnik.

IMO - to szczegolnie dotyczylo pewnej serii napedow jednej firmy,
bodajze Mitsumi.
Czesto im sie cos przyklejalo i rysowalo dyskietke.

Wczesniej nie mialem takich problemow.

>Złapie wilgoci, to nośnik zacznie się kleić i odrywać.

Tego tez nie widzialem.

>> Dyski twarde to zupełnie inna bajka, utrata danych z RAID-1 i
>> RAID-5
>> (związana z uszkodzeniem dysków) zdarza się raz na ileś lat, przy
>> RAID-6
>> lub RAID1+1 itp. w ogóle praktycznie się nie zdarza (pomijając
>> np. awarię zasilania, przepięcia, przegrzania itp. - które niszczą
>> wiele dysków jednocześnie).

>Wiadomo, w końcu też serwerowe dyski wyróżniają sie (chyba...)
>trwałością, kosztem bodajże nieco wolniejszej pracy.

albo szybszej, bo nam zalezy, kosztem ceny :-)

Utrate danych w mirrorze jedna pamietam, ale cos mi sie widzi, ze
jeden dysk padl, serwera (Novell) nikt nie ogladal, az padl i drugi
dysk.

Niedawno polecial mi dysk w laptopie ... ale tak ciekawie, ze prawie
zadnych bledow nie bylo widac, tylko cos system strasznie tym dyskiem
krecil i mial go w 100% zajety.
Zwalalem na antywirusa, na Windows, na upgrade w tle ... az w koncu
kiedys cos mnie tknelo, zmierzylem czas dostepu.
Niektore sektory wymagaly sekundy na odczyt.
Prawie wszytko dalo sie odczytac i skopiowac na nowy, wiec zaufanie mi
wzroslo.

Z kolei SSD mam gdzies w szufladzie padniety - dlugo nie wytrzymal.

>> Oczywiście nie należy zapominać, że istotne dane powinny być gdzieś
>> zduplikowane, w taki sposób, by odpowiednio trudno było je
>> zniszczyć
>> jednocześnie z oryginałem.

>Otóż to!
>Dlatego ówe dane, to u mnie sobie leżały, bo się liczyłem, że
>przeniesienie może się nie udać.

A tu wszyscy poszli w kierunku "synchronizacji".
Jedno przypadkowe klikniecie, i juz po chwili wszystkie kopie danych
sa skasowane :-(

J.

do góry

Użytkownik "Krzysztof Halasa" napisał w wiadomości grup
dyskusyjnych:m...@p...waw.pl...
"J.F." <j...@p...onet.pl> writes:
>>>(Wiem, cyfrowe TRXy mogą to robić nieco inaczej).
>> I kontrargument :-)

>No ale w tamtych czasach tak tego nie robiono (poza ew. armią).

>> dodatkowo dochodzi nam sam TDM - chcemy halfduplex, wiec co
>> najmniej
>> dwie rozmowy na raz, z uwagi na klopoty kto wie czy 4 nie sa lepsze
>> ... no a wybrano 8.
>Tego nie rozumiem. Half duplex? Na niskim poziomie GSM używa
>simpleksu.
>Wyżej jest full duplex (para simpleksów).

Rozmowa jest w dwie strony, wiec duplex, a nie simplex.
Ale pakiety sa na przemian nadawane lub odbierane, wiec half.

To zaleta, ze nadajnik nie przeszkadza w odbiorze, bo w w czasie
odbioru jest wylaczony.
Wiec nawet mimo innych czestotliwosci chcemy tego, co nas zmusza do
wiekszych predkosci.

>Jasne było od początku, że 8 rozmów to nie będzie za dużo.

Ale czemu 8 a nie 4 czy 2 ... no bo na 1 to mamy argument wyzej.

>> glowy nie dam - ale szerszy kanal nie oznacza rowniez szerszego
>> odstepu ?

>No, jeśli np. ze względu na pływanie kwarców to raczej nie.

Chocby i z tego powodu.
Ale kwestia zaniku widma i ewentualnego tlumienia - to wszystko sie
skaluje.

>> Tylko imo latwiej sie dostroic do kanalu, gdzie odstrojenie jest np
>> 1/10 jego szerokosci, niz jak odstrojenie moze siegac 2 kanalow.

>Jasne. W praktyce to może być znacznie więcej niż 1/10, no ale jednak
>musi to wejść przez filtr wejściowy, który ma (w uproszczeniu)
>szerokość
>kanału. Ale można skanować sąsiednie kanały (i tak pewnie trzeba),
>można
>też zrobić sobie tabelkę (i uaktualniać ją na bieżąco) z dryftami vs
>temperatura. Teraz to najprościej użyć jakiegoś 2 ppm TCXO.

Przy tanszych kwarcach zycie moze byc jednak prostsze, gdy nie trzeba
takich cudow :-)

J.

do góry

Użytkownik "HF5BS" napisał w wiadomości grup
dyskusyjnych:oocad7$7n6$...@n...news.atman.pl...
Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
> Użytkownik "HF5BS" napisał w wiadomości grup
>>>Miałem kiedyś dysk, mały, laptopowy PATA, 6 GB. SMART idealny.
>>>[...]
>>>Błąd polegał na tym, że losowo, na odczytany sektor, nakładał się
>>>zapalony piąty bit, przez OR.
>
>> We wszyskich bajtach sektora ?

>We wszyściutkich, ten jeden bit. W każdym przekłamanym ten sam.

>>>Ustaliłem, że miało to związek z intensywnością machania ramieniem
>>>pozycjonera (wykonałem parę prób, tym razem świadomie wywołując
>>>błąd, potwierdziła się zależność od intensywności ruchów
>>>pozycjonera).
>
>> Zrodlo ciekawe ... jakis zimny lut na pamieci/kontrolerze,
>> aktywowany wibracjami ?
>> Bo zeby firmware takie rzeczy robil ... malo prawdopodobne.

>Najśmieszniejsze, że zachowanie dysku nie wskazywało na zimne luty.
>Prędzej,

Bo tylko jeden :-)

>ale tez niekoniecznie, na uszkodzoną kość pamięci bufora, być może,
>nadpęknięty bit miał jakąś zależność od naprężeń mechanicznych, a te
>z pewnością zmieniały się od ruchów siłownika (LITOŚCI - nie
>"aktuatora!!!"),

Tylko kosc ma w srodku wieksza matryce.
PATA z kolei 16-bit.
Jesli pamiec 8-bitowa, to by mi zimny lut pasowal.
Chyba, ze w jakims chipie interfejsu, albo sciezce pomiedzy.

>> O ile w ogole dane sa tam programowo mieszane - przeciez to szybkie
>> ma byc
> :-)
>>>I teraz - pomoże mi głosowanie?
>
>> Jak najbardziej - bierzesz 3 backupy i skoro to w losowym sektorze,
>> to bity, bajty czy caly sektor w dwoch powinny byc dobre, a trzeci
>> sie odrzuci.

>Tylko co, jak z 3 odczytów dwa będą zdupcone?

No to trzeba bylo sobie pluc w brode, ze nie bylo ich 5 :)

>> Nie robisz trzech backupow naraz ?
>> A to masz pecha :-)

>Nawet 3 nie gwarantują...

Nic nie gwarantuje ...


J.

do góry

Użytkownik "HF5BS" napisał w wiadomości grup
dyskusyjnych:oocb8q$obl$...@n...news.atman.pl...
Użytkownik "Jarosław Sokołowski" <j...@l...waw.pl> napisał w
wiadomości
>>> I teraz - pomoże mi głosowanie?
>> Gdyby tych dysków było dajmy na to pięć, to by pomogło. Ale to
>> marna
>> stratega przy tak dużych zbiorach danych. Natomiast RAID sprawdza
>> się
>> znakomicie.

>Z pewnością, po coś te technologie stworzono. Ale ja z tych jestem,
>co to nie zawierza bezkrytycznie rajdom zero, jeden, pięć, dziesięć,
>milion, srylion, pierdylion, z życia wiem, że można się mocno naciąć.
>Np. z powodu wykorzystania CRC-attack... Albo czegoś w podobie.

Mowimy o przypadkowej awarii, czy celowym ataku ?
Pr-stwo przypadkowego uszkodzenia i zachowania CRC jest raczej male.

>Wspieram się, oczywiście, korzystam, gdy jest, głupotą było by to
>olać. Ale pozostaję sceptyczny. Niby jest np. korekcja z RSC, ale,
>czy jeśli mam spadaczony tak dysk, to jest w ogóle sens jego
>obecności? Nie da mi tego samego efektu, tego dysku usunięcie i
>korzystanie z dobrodziejstw matryc RSC, tak czy siak, będzie trzeba
>je wykorzystać, to może zamiast dziabać z błędnych sektorów, w ogóle
>je wyrzucić?

Ale to IMO dwie calkiem rozne sprawy.
Kody korekcyjne umozliwiaja odtworzenie danych, ktore zostaly
utracone.
Glosowanie tez, tylko jest znacznie bardziej kosztowne.
Obie metody dzialaja, o ile zakres strat nie jest zbyt duzy.
Co ma zreszta istotny wplyw na zakres stosowalnosci.

W obu faktycznie dobrze byloby wymienic uszkodzone nosnikow ... no
coz, mozna zaoszczedzic i nie wymieniac bez potrzeby, ale
bezpieczenstwo spada :-)

RAID tez jest forma kodu korekcyjnego ... ale wymaga CRC, czy innej
metody okreslenia, ktoremu dyskowi nie mozna wierzyc :-)
CD dobrze zrobili, rysy nie przeszkadzaja.

Mozna by zrobic RAID w polaczeniu RSC (o ile to Reed Solomon Code).

J.

do góry

Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
news:59b184ee$0$651$65785112@news.neostrada.pl...
...
> RAID tez jest forma kodu korekcyjnego ... ale wymaga CRC, czy innej metody
> okreslenia, ktoremu dyskowi nie mozna wierzyc :-)
> CD dobrze zrobili, rysy nie przeszkadzaja.

O ile nie będą to rysy od spodu, bo wtedy to tylko wachlarzyk do owiewania
się w upały.

> Mozna by zrobic RAID w polaczeniu RSC (o ile to Reed Solomon Code).

Ano, o ten RSC mi chodzi i nie wiem, czy mnie gdzieś po oczach nie gwizdnęło
przy czytaniu o macierzach...
Chciałem któregoś wieczora rozkminić, jak to jest liczone, aby dla zabawy
napisać sobie własny program, który to wykorzystuje, ale szybko odpłynąłem,
a później już nie szukałem.

--
Psy kochają przyjaciół i gryzą wrogów,
w odróżnieniu od ludzi, którzy niezdolni są do czystej miłości
i zawsze muszą mieszać miłość z nienawiścią.
(C) Zygmunt Freud.

do góry

Użytkownik "HF5BS" napisał w wiadomości grup
dyskusyjnych:ooscv7$3lh$...@n...news.atman.pl...
Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
>> RAID tez jest forma kodu korekcyjnego ... ale wymaga CRC, czy innej
>> metody okreslenia, ktoremu dyskowi nie mozna wierzyc :-)
>> CD dobrze zrobili, rysy nie przeszkadzaja.

>O ile nie będą to rysy od spodu, bo wtedy to tylko wachlarzyk do
>owiewania się w upały.

Od spodu tez moga byc, az tak bardzo nie przeszkadzaja.

Poza tym spod mozna wypolerowac, a od gory tylko cienka warstwa
lakieru i zaraz dane.

>> Mozna by zrobic RAID w polaczeniu RSC (o ile to Reed Solomon Code).
>Ano, o ten RSC mi chodzi i nie wiem, czy mnie gdzieś po oczach nie
>gwizdnęło przy czytaniu o macierzach...
>Chciałem któregoś wieczora rozkminić, jak to jest liczone, aby dla
>zabawy napisać sobie własny program, który to wykorzystuje, ale
>szybko odpłynąłem, a później już nie szukałem.

Kiedys nawet wiedzialem, ale troche wywietrzalo.
Tak czy inaczej - dziala. Przy niewielkiej liczbie przeklamanych bitow
mozna odtworzyc oryginal, nie wiedzac ktore sa przeklamane.

J.

do góry

Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
news:59b273e5$0$5153$65785112@news.neostrada.pl...
>>O ile nie będą to rysy od spodu, bo wtedy to tylko wachlarzyk do owiewania
>>się w upały.
>
> Od spodu tez moga byc, az tak bardzo nie przeszkadzaja.

Oj, ja chyba się źle wyraziłem (zmęczenie nową pracą) - chodziło mi o
uszkodzenie strony, gdzie jest zapis, o sytuację, gdy rysa zadrapie porcję
bitów i średnio będzie z czego odtworzyć.
Przyz "rypaniu" płyty audio, w takiej sytuacji, zadziwiająco poprawiało
wynik wyłączenie kontroli błędów.

>> Poza tym spod mozna wypolerowac, a od gory tylko cienka warstwa
> lakieru i zaraz dane.

O te dane się martwię. Najgorsze, gdy nawet cieniutka rysa, ale wzdłuż.

(RSC)
>>Chciałem któregoś wieczora rozkminić, jak to jest liczone, aby dla zabawy
>>napisać sobie własny program, który to wykorzystuje, ale szybko
>>odpłynąłem, a później już nie szukałem.
>
> Kiedys nawet wiedzialem, ale troche wywietrzalo.

Podobnie jak ja z AX25, wystarczył mi rzut oka na ramkę i już wiedziałem, co
się dzizje. Przypuszczam, że dziś szybko bym sobie przypomniał, kilka lat
ślepienia się w monitor kanału z latającymi pakietami (Packet Radio)...

> Tak czy inaczej - dziala. Przy niewielkiej liczbie przeklamanych bitow
> mozna odtworzyc oryginal, nie wiedzac ktore sa przeklamane.

Więcej, to jest w stanie odtworzyć nawet kilka utraconych plików, jeśli
tylko ilość straconych danych nie przekracza możliwości naprawczych.
Przynajmniej w wersji binarek usenetowych - PAR2.
Nie wiem, jakie są losy PAR3, podobno coś jeszcze lepszego, niż PAR2, który
opiera się o rozwiązanie z kodem RSC.

--
Psy kochają przyjaciół i gryzą wrogów,
w odróżnieniu od ludzi, którzy niezdolni są do czystej miłości
i zawsze muszą mieszać miłość z nienawiścią.
(C) Zygmunt Freud.

do góry