Kérdezz, jár erre pár guru. Hamarabb kapsz választ, ha precízen leírod mi a baj (oprendszer, sw verzió, hibaüzenetek, egyéb) - de kérünk, egy kérdést ne írj bele több topicba, kérdezés előtt keress vissza, hátha már volt a problémád.
Ja, és amennyiben warez windowsod lenne, ez nem az a hely ahol segítene bárki. És kodekpakkot, soha, sehova sem teszünk fel.
Mármint nem feltétlenül a diszken keletkezik a bitflip (bár keletkezhet ott is, a mágneses réteg ellustulásától), de akárhol is keletkezik a folyamat során, non-ECC RAM esetén is a diszken köt ki. Így szerintem csak a megoldás szempontjából van jelentősége az okának, a hiba szempontjából közömbös, hogy honnan került a diszkre mert a lementése után biztonsági okokból úgysem lesz tovább használva csak akkor, ha bizonyítottan más alkatrész okozta.
"Mire az elromlott lemez szinkronizálását befejezte, arra pont el is hullott egy következő."
Hát ja, ld. még RAID5-halál címszó alatt!
Azóta már min. RAID6-ot használunk (aminek van is valami értelme, szemben a RAID5+hot spare 'megoldással'), másrészt nem véletlenül van beépítve a storage-cuccokba (tipikusan már a firmware-ekbe) a korábban említett disk scrubbing, ami időben ki tudja buktatni a problémákat.
Ad 1. Oszt' mijaf@szt csinyájjak linuxon egy vélhetően vindózos progival, amiről azt se tudni, hogy' müxik a gyakorlatban? (Tudom, tegyem föl a linuxos verziót.... Megnéztem, mi ez, nem kell.)
Ad 2. Megint mondom: tökmindegy, mi az algoritmus meg a progi, nyilván nem lehet hibátlanul kibontani egy összefirkált tömörítvényt!
Bocsi, de megint fogalmad sincs, miről beszélsz...
A kibontásos példa a biztosan hibátlan(ul letöltött, pl. md5sum vagy effélével ellenőrzött) fájlokra vonatkozik! (OK, ezt valóban nem emeltem ki...)
Amikor egy tömörítővel "ellenőrzöl" egy fájlt, az NEM olvassa végig a tartalmat, csak a metaadatokat nézi! Ha valahol egy becsomagolt fájlon belül van hiba, az ott nem fog kibukni!
Ebből a szempontból a tömörítés algoritmusa érdektelen, de maguk a tömörítő alkalmazások term. viselkedhetnek eltérően, akár ugyanannak az algoritmusnak más oprendceren futó progija is...
"Fileokról meg egyenbekről volt szó, a majom a dénest teljesen kreténmódon keverte ide."
Há'perszehogy, épp erre utaltam, ugyi...
Annyi öszefüggés lehet, hogy egycerü esetekben az említett infók lehettek egy konkrét diszken egy konkrét fájlban (ill. azon belül egy konkrét fizikai szektor[csoport]ban), ahol a jelenség valóban felléphetett.
Akkoriban több cikk volt ezekről, most csak ezeket találtam hirtelenjében. A Netflixesnél is leírták, hogy az adatbázis esett szét hardverhiba miatt keletkezett néma adatsérüléssel (utolsó mondatban a lényeg):
"On Monday, 8/11, our monitors flagged a database corruption event in our shipping system. Over the course of the day, we began experiencing similar problems in peripheral databases until our shipping system went down... We suspected hardware and moved the system to an isolated environment, gradually getting shipments moving again. Eventually the system was repaired and shipping returned to normal conditions. With some great forensic help from our vendors, root cause was identified as a key faulty hardware component. It definitively caused the problem yet reported no detectable errors."
Hozzám is hoztak be már olyan RAID5 tömböt amit visszaíró cache-el használtak és miután a 4 (nem ECC) RAM modulból a CPU-hoz közelebbi kettő megadta magát vagy a hőterheléstől vagy az elöregedéstől (mindkettőnek a paneljén felszakadt egy-egy chipnek egy-egy lába), így egy adatfelmásolás után szétesett a tömb a cache-ben keletkezett néma bithibák miatt, ami az ECC hiányában nem derültek ki azonnal. Szerencséjükre relatíve frissen keletkezett a probléma és csak kevés fájlt érintettek a hibák, így majdnem minden menthető volt.
Facebookosat elolvastam, de mi van benne? Valami frissítés közben elszálltak lemezek, az most vagy igaz vagy nem, vagy az volt vagy nem, ezért nem mutatta meg a fotókat, de később már igen. Szóval adatvesztés nem volt, a részleteibe meg nagyon nem mentek bele, nem nekünk való bulvár. Többit meg sem nyomom, nyilván Face másra és másképp való, ha éppen nincs ott a poszt vagy nem jelenik meg valakinek, azt sem tudni, hogy hiba-e vagy állapot és folyton dőlborul valami, eleve posztok csilliárdjai és képek tricsillirádjai kerülnek fel rá minden másodpercben. Másfajta kiszolgálásról szól az egész.
Netflixet is megnyomtam, első ránézésre semmi indokot nem írnak, hogy mi történt és miért, csak nem megy a DVDküldés, csókolom. Akkor itt mi is történt?
És akkor emlékezzünk meg egy 20 éves Hitachi tárolóról amit VÉGRE kiselejtezhettem, sorban döglöttek meg a lemezek, de még csak lassulás sem volt, már szinte napi 2 HDD-t cseréltem, mire a végére értünk. Hangos, zabál, embernyi magas rackben 600 gigás vincsikből ha minden igaz, akkor redundánsan kijött a 8 terabyte. Mire az elromlott lemez szinkronizálását befejezte, arra pont el is hullott egy következő. Oszt akkor hol a hiba? Annak aztán kihúzhattam a villanyt is, de ott voltak a kövület fapados MSAk, meg mindenféle jobbak, én azért láttam fényképen is viszonylag nagy EMC tárolókat, DASt. jó ég tudja miket szerteszéjjel. Nem kell mindenáron szoftverben és egyébben alulméretezett rendszert működtetni vagy ne érjen el egy olyan csoda FW hiba, mint pár éve a HPnál, aztán meg is vagyunk.
Már feltalálták a .zip vagy .7z tömörítést. Ami ott van mindenkinél.
De javaslok jobbat: egy .vhd file ntfs partícióját bitlockerrel titkosítsd le és másolj rá egy nagyobb txt filet. Oszd meg a jelszót. Na ebben egy-két 4kB részt nullázz ki, mintha a hdd szektora megdöglött volna vagy áramszünet/fagyás miatt átíródott volna.
Na ekkor (a 4kB részt kivéve) vissza tudjátok-e olvasni a txt filet?
Na, próbáljátok kicsomagolni, a 10001 bájtos "pi10k.txt" fájlt, az archívumból. (Nevezzétek át pi10k.txt...zpaq-ra, különben kiterjesztés nélküli fájlt kaptok.)
Teszteléshez: zpaq.exe x pi10k_damaged.zpaq -test
Kicsomagoláshoz: zpaq.exe x pi10k.txt_damaged.zpaq -to unpacked
Le volt már TÖLTVE a fájl, meg volt nyitva a WinRAR-ban és bele lesegettem a különféle állományokba, az "Alt-V" helyi parancs használatával, a WinRAR beépített fájlnézőkéjével. Az egész archívum hibátlan volt, a tesztelés folyamán, még mielőtt bármi egyebet csináltam volna vele. Már, túl voltam a 20.-ik fájlon és egyszer csak fogta magát és megkotlott az archívum! A sok ezer, ha csak nem 10-20k feletti számban megnyitott, kicsomagolt, becsomagolt, tesztelt archívum után ez volt az első alkalom, amivel ez történt. Igaz, *.xz állományokat elég ritkán töltök le, kerül a szemem elé, talán csak pár tucatot ha össze lehetne eddig számolni. Ha, 7z-ben lett volna, mint konténerbe lett volna rakva az adat és ugyanígy tömörítve, vajon megsérült volna-e?? Erre akartam utalni lentebb, valahol van is egy angol nyelvű cikk/okfejtés, ahol pont erről a sérülékenységről van szó, az újabb LZMA-család kapcsán.
"hogy a DNS zóna-adatok tipikusan ritkán változnak"
Fileokról meg egyenbekről volt szó, a majom a dénest teljesen kreténmódon keverte ide. Idézhetnék még 1-2 oldalt, teljesen felesleges lenne. Ahhoz az állapothoz ragaszkodott, mint valami C64es magnó, hogy ha sokat olvassuk akkor romlik az állapota és kell egy nem használt állapot vagy mi. Nem, nem lemez hibák, nem felhő, nem kötet,nem ilyesmikről meg memória hibákról volt szó.
Bizonyos esetekben, főleg régebben előfordulhatott. Pontosabban: most is előfordulhat pl. egy 'szóló', ritkán használt diszken. A Jahno ápoltjának az állítása viszont ettől még nettó f@szság.
Annyi valóságalapja régen lehetett, hogy a DNS zóna-adatok tipikusan ritkán változnak, ezért egy régebbi és/vagy csak egyszerűbb felépítésű szerveren nyilván ezeknél jelentkezett a hiba.
Komolyabb helyeken/eszközökben viszont ma már megvannak a megoldások a kivédésére: többszörös redundancia (úgy a lemeztömbön belül, mint komplett storage-szinten), 'erősebb' hibajavító kódok (ellenőrző összegek), (a háttérben) a tartalom automatikus+folyamatos fizikai ellenőrzése+újraírása, stb, stb.
"Elég csak egyetlen egy bitnek 0-ból, 1-esbe átfordulni vagy 1 -> 0 irányba és lehet akkor kuka az egész adat!"
Öööö... nem!
Bájtonként 1-2 bithibát már igen régóta tudnak detektálni, és többnyire javítani is az eszközök úgy a tárolás, mint az adatátvitel esetén.
"Különösképp tömörített fájloknál. A mai modern tárolóegységeknél, elég egy kósza neutron, kozmikus sugárzásból származó nagy energiájú foton és meg van a baj. Nem kell hozzá, áramszünet, egyéb zűr, hogy olvasási probléma legyen."
A mai modern tárolóegységeknél pont nem elég egy ilyen hiba az adatvesztéshez (ld. feljebb)!
"Egyszer, leszedtem egy *.xz kiterjesztésű tömörített archívumot, pár hónapja, asszem LZMA2-vel volt tömörítve (a régi LZMA, valamivel biztonságossabb!) és a huszadikon túli fájlkicsomagolás után, egyszer csak megkotlott a fájl! 0-át mutatott utána a WinRAR, gallyra ment. Csinálj egy új RAR/7Z archívumot, aztán random helyeken, 1 bájtot rontsál el rajta... (pl: 76 helyett 75 legyen hex-ben.) és nézd meg mi történik!"
A tömörített fájlok az esetek túlnyomó részében letöltéskor, átviteli hiba miatt mennek gaJra. Ha pedig többszöri kísérletre sem sikerül letölteni egy nagyobb fájlt, akkor a köv. javasolt lépés a memóriateszt! :O
Az pedig a tartalmuk struktúrájának természetes következménye, hogy egy hiba nagyobb "rombolást" okoz bennük, mint egy sima szövegben. Logikailag nincs különbség: 1 rossz bájt az itt is, ott is csupán 1 rossz bájt!
Igen, létezik ez a jelenség, sajnos. Ennek, részben kvantrummechanikai okai is vannak. Az entrópiának is szerepe van benne. Elég csak egyetlen egy bitnek 0-ból, 1-esbe átfordulni vagy 1 -> 0 irányba és lehet akkor kuka az egész adat! Különösképp tömörített fájloknál. A mai modern tárolóegységeknél, elég egy kósza neutron, kozmikus sugárzásból származó nagy energiájú foton és meg van a baj. Nem kell hozzá, áramszünet, egyéb zűr, hogy olvasási probléma legyen.
Egyszer, leszedtem egy *.xz kiterjesztésű tömörített archívumot, pár hónapja, asszem LZMA2-vel volt tömörítve (a régi LZMA, valamivel biztonságossabb!) és a huszadikon túli fájlkicsomagolás után, egyszer csak megkotlott a fájl! 0-át mutatott utána a WinRAR, gallyra ment. Csinálj egy új RAR/7Z archívumot, aztán random helyeken, 1 bájtot rontsál el rajta... (pl: 76 helyett 75 legyen hex-ben.) és nézd meg mi történik!
Kellene egy meggyőző alkalmazás, talán egy tűzfal? ami bizonyítja, hogy a gmail nem hallgatózik állandóan, és amikor megnyitja az app-ot, hogy mikor megy a busz, azt a gmail nem fogja elmenteni, hogy mikor és merre ment és ott kivel mit beszélt.
Tűzfalról nem tudok, de adatfigyelés van a moblilon.
Van olyan app, amiből lehetne látni, hogy ott csak pl. a térképek megjelenítéséhez használtak adatforgalmat és semmilyen app nem küldött adatot a gmail-nek?
Vagy egy tanulmány erről, akik végeztek ilyen irányú kutatást és ezt publikálták valahol?
