Nem ECC ramot tartalmazó pc-knél fájlmásoláskor néha előforduló bithibák kiküszöbölése végett keresnék olyan fájlkezelőt, ami képes a másolat bitre pontosságának automatikus ellenőrzésére.
Linuxra és Windowsra is.
(Az olyanoktól kíméljetek, hogy "ilyen nem fordulhat elő, ha jó a ramod", meg "átmásolod akármivel, és aztán így meg úgy leellenőrzöd". )
Köszi előre is!
- 8195 megtekintés
Hozzászólások
Fontos és engem is érdeklő témát feszegetsz ezzel. Nehezítés: másoláskor a memóriában és a diszk RAM-jában is gyorsítótárazódik az anyag. Ez alkalmas arra, hogy megtévesszen egy ilyen ellenőrzés során.
rsync programmal másoltam eddig. Átrántottam a fájlokat, majd erőteljesebb diszkműveletekkel ürítettem a gyorsítótárakat és újrajátszottam a rsync-et a -avc (=checksum) opcióval. Ha valamit ekkor átmásolt (mert nem egyezett), akkor az hibás másolásra utalt a két másolás egyikénél az újramásoláskor kiírt fájl(ok)ra.
De még ez sem 100 %, mert ha hülye véletlen folytán ugyanarra a memóriaterületre vagy akár csak hasonló jellegű bithibával rendelkező memóriaterületre kerülnek a fájl byte-jai, akkor az eredeti forrásból való felolvasás és az ezután történő ellenörző összeg készítés már a hibás adatról történik, azaz megfelel az ellenörző összeg a már hibás adatra (!!).
Ezzel eljutunk oda, hogy már a fájl keletkezésekor kell egy sha1-es ellenörzőösszeget minden fájl mellé tenni, amely a fájlt a teljes élete során végigkiséri és ez alapján ellenőrizhető.
Ezt például cron-ból lehet rendszerese megcsinálni minden olyan fájlra, amely újabb módosítási idejű, mint a mellette (esetleg nem is) létező sha1. És figyelve arra is, hogy a módosítási ideje ne az utolsó 1-2 percet takarja, mert ez annyit is jelenthet, hogy most másolják fel. Lásd: sha1sum parancsot.
Szigorúan véve tehát nem tudsz olyan másoló programot, amely az esetleg hibás RAM esetén másoláskor dönti el, hogy ténylegesen az eredeti tartalom lett-e áthelyezve, mivel a memóriahiba átverheti már a tartalom ellenőrzőösszegének készítése előtt. Csak az eredeti példány keletkezésekor lehelyezett SHA1 és ezzel való végigkísérés ad megbízható megoldást.
- A hozzászóláshoz be kell jelentkezni
Ha megsérülhet az ellenőrzőösszeg, akkor az eredeti példány keletkezésekor számolt és állományba írt összeg is sérülhet, akár a számoláskor, akár az íráskor, akár a visszaolvasáskor. :?
:)
- A hozzászóláshoz be kell jelentkezni
Azt viszont észreveszed. Ugyanis annak esélye, hogy egy SHA1 úgy alakuljon át, hogy az eredeti adat módosulása is éppen jó legyen rá, hát a lottó 5-öst már 10-szer megnyerem addig.
Ez egy nem kis különbség.
- A hozzászóláshoz be kell jelentkezni
nagyobb a (matematikai) esélye, mint hinnéd!
hint: birthday-attack
- A hozzászóláshoz be kell jelentkezni
Akkor - ha jól veszem ki a szavaidból, a napjainkban elterjedten használatos ellenörző összegekben (CRC32 az ethernet kereten, SHA1 a fájl mellé) nem bízhatunk meg, mert gyakori az a jelenség, hogy az ellenőrzöösszeg is oly módon sérül és az adat is, hogy helyes lesz a sérült adatra.
Konkrétan milyen esélyek vannak erre?
- CRC32 az 1500 byte-os ethernet keretre
- SHA1 egy 100 MB ... 1 GB közé eső fájlra?
- A hozzászóláshoz be kell jelentkezni
azt mondtam, hogy gyakori jelenség?
"Konkrétan milyen esélyek vannak erre?
- CRC32 az 1500 byte-os ethernet keretre
- SHA1 egy 100 MB ... 1 GB közé eső fájlra?"
Honnan a tokombol tudjam?
erdekesseget kozoltem veled, hint-et is kaptal, nezz utana ha erdekel, hogy ezeknek mik az eselyei.
- A hozzászóláshoz be kell jelentkezni
Otthonra megteszi. Főleg a lottó ötös.
:)
- A hozzászóláshoz be kell jelentkezni
Vedd észre, hogy csak azt tudod, hogy a fájl és az SHA1 nem feleltethető meg egymásnak, azt viszont nem tudod, hogy azért-e, mert a fájl, vagz azért-e, mert az SHA1 "hibás" - azaz került bithibával a memóriába, ahol az ellenőrzés zajlik.
- A hozzászóláshoz be kell jelentkezni
A rendszer duplikálta a hozzászólásomat. Töröltem.
- A hozzászóláshoz be kell jelentkezni
(Csak megjegyzem: echo 1 > /proc/sys/vm/drop_caches)
Nem az a leggyakoribb, hogy egy modul/terulet bithibas es mindig rossz ott, hanem az a gyakoribb, hogy a bit csak ugy random atvalt. Se elotte nem tette soha, sem utana nem teszi, de akkor eppen olyan kedve volt.
Sajnalatosan a bitek josaga (megbizhatosaga) nem nott az utobbi evekben olyan tempoban, ahogy a memoriamodulok vagy a diszkek kapacitasa nott. Azt kell most mondjam, hogy 20T adat vegigolvasasaval inkabb beleszaladsz random bithibaba, mint nem. A diszkek mindenkepp rendelkeznek ellenorzoosszeggel, a memoria nem mindig. A memoria, meoriabusz, cpu regisztereknek mind-mind ECC kell, hogy az egesznek ertelme legyen.
A file szintu integritas-vedelem szep gondolat. Nem lenne lehetetlen olyan filerendszer ahol ezt kriptografiai modon oldanak meg, metaadatban tarolva a hash-t. Azonban nem ismerek ilyet. Block szintu vedelem tobb filerendszerben van, az konnyebben hasznalhato es konnyebben implementalhato is. Kapott mar el diszkhibat ZFS ilyen modon.
Az integritasvedelem vegigvitele a filesystem-cache-utility utvonalon viszont inkabb csak nem teljesulo abrand. Marad az okos utility vagy a kezi osszehasonlitas.
- A hozzászóláshoz be kell jelentkezni
"Marad az okos utility"
Ha lenne... :)
- A hozzászóláshoz be kell jelentkezni
Szerintem a FastCopy tudja. Beépül az Intézőbe. Parancssorban is használható, vagyis a jobb fájlkezelőkben konfigurálhatod, hogy ezzel menjen a másolás, vagy ráteheted egy gombra/gyorsbillentyűre.
:)
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
Ráadásul ez titkosított állományoknál pedig kritikus.
- A hozzászóláshoz be kell jelentkezni
es nem is hulyeseg az igeny, meg a felvetes, ha jobban belegondolok, nem egyszer fordut mar elo, hogy tobb terabajtos zpool-oknal a zpool scrub jelezte, hogy javitott par checksum error-t...
- A hozzászóláshoz be kell jelentkezni