Pokvarjeni podatki pri kopiranju čez mrežo

Slabi kabli maybe ? Zna to bit, meni je dok nisem imel cat 6, po mreži enga filma ni preneslo kot se spodobi, pa nimam kej dost metrov nekje cela mreža šteje 100-120 metrov nikjer pa ni dlje kot 15m razlike med routerjem in switch-em. Sem kasneje pogruntal (ma ne 100%) da bi znal bit kriv en od diskov ali ram na serverju, menjal oboje in sedaj se ne dogaja več, ne vem pa kaj še dans kaj je bilo.

Kabel tester, ampak malo boljši kot uni kitajci.

Diski niso, saj na cilju sta dva (če bi en imel napačne podatke, bi ReFS prebral z drugega).
Na source pa je v drugem poskusu bral pravilno. Torej zapis je OK. Edino če je spet bil kaki bug v firmware HDD.

Nekoč sem imel problem z zunanjim USB ohišjem za disk, imel je dva jumperja, master in slave, v enem načinu mi je koraptalo večje datoteke.
Drugič sem imel problem z USB na LAN D-Linkovim pretvornikom. Če sem preko mreže na računalnik prenašal datoteko, ob tem sem pa odpiral Gmail, mi je namesto da bi mi odprlo Gmail, v tistem trenutku udarilo Blue screen (100% ponovljivo).

Tako da..., narobe je lahko karkoli.

Kar se tiče TCP/IP bi skoraj rekel, da ga je varno izvzet kot možnega kandidata za napako. Kot sam ugotavljaš, imaš checksum v L2 frameu, nato še v TCP segmentu, preko katerega gre navadno SMB. Ne vem, a SMB sam kaj preverja CRC ali kaj podobnega...?

Kakor koli - če bi bil kabel ali kateri koli del TCP/IP stacka tako okvarjen, da bi dejansko dopuščal napake pri prenosu, bi si predstavljal, da bi stalno dobival kritične napake, npr., ne bi mogel niti brskat po NAS-u z Explorerjem. To, da v 99,99% dela, v 0,01% pa se pojavijo napake, skoraj zagotovo ni posledica napak pri prenosu.

Je pa možno, da gre za napake pri branju izvornih podatkov z diska, ali pa za napake pri zapisovanju na ciljni disk.

Glej CRC Checksum missmatch transfering large files to NAS @ serverfault

če JE krivo kopiranje z explorerejm, probaj FastCopy. Meni zelo ljub program, ma kar nekaj funkcij, ki jih windows nima pri kopiranju. Prenesi ga, odpri help in preberi kaj vse zna. Najbrž zna dovolj :)

To sicer drži, vendar še vedno drži imagodei-jeva trditev, da do težave na L2 ne prihaja. Intelove mrežne imajo večino funkcij hardwersko implementiranih, medtem ko Realtek stvari rešuje softwersko, zato lahko prihaja do težav, če je procesor preobremenjen.

Pred leti sem imel podoben problem...zaradi driverja mrežne kartice. Probaj menjati gonilnik z novejšim, starejšim, univerzalnim.

memtest86+ v5.01 je tekel 22 ur (7 prehodov) brez napak, na source sistemu.

Sem naredil 10 kopij na enak način in so vse OK. (izvorni fajl je bil zdaj drugi, ker sem original vmes izbrisal; za ta test sem ga iz serverja skopiral nazaj na Medion-a)

Prav tako sem naredil 170 krat md5sum tega fajla na Medion-u. Vsakič je bil pravi.

Kaki predlogi za HD test? Trenutno poganjam H2testw.

Saj... Sprašujem, če ima kdo kaki "preferred" tool.

si sploh lahko kdaj sproduciral ta error al je bil to one time thing ?

jst se nebi sekiral, mogoče si mel pač once in a life time nesrečo da so ti kozmični žarki ponagajal :)

Studies by IBM in the 1990s suggest that computers typically experience about one cosmic-ray-induced error per 256 megabytes of RAM per month

To ni once in lifetime. Pri 16GB RAM-a je to ... 2 krat na dan!

Kar sicer smells like you-know-what

S.M.A.R.T podatki vseh udeleženih diskov so OK.

En disk v mirrorju (na serverju) sicer ima 2-4 bad sektorje, ampak:
- so stari in na koncu diska, ki sem ga pustil neparticioniranega. Tak je že leta.
- ker je mirror, je kopija podatkov na drugem disku, ki nima težav.

hojnikb je 12. mar 2017 ob 21:22 izjavil:

in veseljaki bi radi laufal zfs na nonecc ramu :)

Tudi če je recimo 1 error na mesec, je to katastrofalno (za zfs anyway) :)

tole ne drži čisto. če pišeš pokvarjene podatke kamorkoli bodo pokvarjeni. zfs al pa ne.

integriteta podatkov na zfs pa bo čisto lepo preživela brez ecc rama, tudi nobenih podatkov ti ne bo corruptal pri branju zaradi bit flipov, ker bo sproti popravljal podatke iz rezervnih kopij / parity diskov. ko ne najde zdrave kopije pa ne popravlja več nič ampak vrže ven unrecoverable error. in če so ti errorji zaradi rama, bo zadeva špilala naprej ko boš zamenjal ploščico.

tudi pri resilveringu je zadeva ista. ko nebo zdravih kopij, error, podatki ostanajo kot so. da bi ti ram uničil podatke pri resilveringu, bi moral ram za vsak prebrani block flipniti bite tako, da nastane checksum collision.

seveda pa je priporočljiva uporaba ECC, tako kot povsod, kjer je pomembna integriteta podatkov.

@MrStein: Po mojem ti je Akoya "pokvarla" podatke. zdaj ali je bil to gamma ray, bit flip, ...

no, pa grema scrubbat:

- preberemo checksum za podatke
- preberemo podatke in izracunamo checksum
- če sta ista, vse OK, gremo dalje
- če nista ista
---preberemo kopijo/parity in izracunamo checksum.
---če sta checksuma ista, popravi original / markira bad block, gremo dalje
---če po vseh obstoječih kopijah ne najde istega checksuma, bo vrgo ven unrecoverable error in VSE podatke pustil pri miru.

ne bo pa zfs prepisoval podatkov samo zaradi tega ker checksumi niso isti.

da pa ti sam ZFS zapiše corruptane podatke pri scrubingu, pa more ram bite obrniti tako da pride do SHA256 kolizije.

ZFS se ne zanaša na NIČ, razen sebe. če zapišeš na zfs corruptane podatke, zfs s tem nima nič. za njega so ti podatki OK. TI moraš poskrbeti, da do ZFS-ja pridejo pravi podatki. tu pa ti sam ECC ram v zfs mašini bolj malo pomaga. (no, en breaking point manj).

edit: tudi sam sem prvo mislil da je ecc obvezen (boš verjetno najšo kakšen moj post na s-t glede tega), ampak izkazalo se je da baba čula baba rekla, ni glih zanesljiv vir informacij

Baja je 13. mar 2017 ob 10:45 izjavil:

no, pa grema scrubbat:

- preberemo checksum za podatke
- preberemo podatke in izracunamo checksum
- če sta ista, vse OK, gremo dalje
- če nista ista
---preberemo kopijo/parity in izracunamo checksum.
---če sta checksuma ista, popravi original / markira bad block, gremo dalje
---če po vseh obstoječih kopijah ne najde istega checksuma, bo vrgo ven unrecoverable error in VSE podatke pustil pri miru.

ne bo pa zfs prepisoval podatkov samo zaradi tega ker checksumi niso isti.

da pa ti sam ZFS zapiše corruptane podatke pri scrubingu, pa more ram bite obrniti tako da pride do SHA256 kolizije.

ZFS se ne zanaša na NIČ, razen sebe. če zapišeš na zfs corruptane podatke, zfs s tem nima nič. za njega so ti podatki OK. TI moraš poskrbeti, da do ZFS-ja pridejo pravi podatki. tu pa ti sam ECC ram v zfs mašini bolj malo pomaga. (no, en breaking point manj).

edit: tudi sam sem prvo mislil da je ecc obvezen (boš verjetno najšo kakšen moj post na s-t glede tega), ampak izkazalo se je da baba čula baba rekla, ni glih zanesljiv vir informacij

Problem je v tem, da se tako podatki kot checksumi pri kakršnikoli obdelavi prehodno shranjujejo v ramu.

Your application wishes to write "11001011", but due to your Bad RAM, you end up with "11000011". As a result, "11000011" is sent to ZFS to be stored. ZFS adds a checksum to "11000011" and stores it in the pool. You have data corruption, and ZFS doesn't know any different. ZFS assumes that the data coming out of RAM is intentional, so parity and checksums are calculated based on that result.

But what happens when you read the data off disk and store it back in your faulty non-ECC RAM? Things get ugly at this point. So, you read back "11000011" to RAM. However, it's stored in _almost_ the same position before it was sent to disk. Assume it is stored only 4 bits later. Then, you get back "01000011". Not only was your file corrupt on disk, but you've made things worse by storing them back into RAM where the faulty hardware is. But, ZFS is designed to correct this, right? So, we can fix the bad bit back to "11000011", but the problem is that the data is still corrupted!

Things go downhill from here. Because this is a physical hardware failure, we actually can't set that first bit to "1". So, any attempt at doing so, will immediately revert it back to "0". So, while the data is stored in our faulty non-ECC RAM, the byte will remain as "01000011". Now, suppose we're ready to flush the data in RAM to disk, we've compounded our errors by storing "01000011" on platter. ZFS calculates a new checksum based on the newly corrupted data, again assuming our DIMM modules are telling us the truth, and we've further corrupted our data.

As you can see, the more we read and write data to and from non-ECC RAM, the more we have a chance of corrupting data on the filesystem. ZFS was designed to protect us against this, but our chain is only as strong as the weakest link, which in this case is non-ECC RAM corrupting our data.

Vir: https://pthree.org/2013/12/10/zfs-admin...

@Modri Dirkač: saj ne pravim da laufam zfs na non-ecc ramu.

@Miha 333: ampak tvoj primer velja za vse FS-je. kateremu koli FS-ju boš šibo napačne podatke, bodo podatki napačni.

iz: http://jrs-s.net/2015/02/03/will-zfs-an...

I don't care about your logic! I wish to appeal to authority!

OK. "Authority" in this case doesn't get much better than Matthew Ahrens, one of the cofounders of ZFS at Sun Microsystems and current ZFS developer at Delphix. In the comments to one of my filesystem articles on Ars Technica, Matthew said "There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem."

jype je 13. mar 2017 ob 11:05 izjavil:

imagodei> Kar se tiče TCP/IP bi skoraj rekel, da ga je varno izvzet kot možnega kandidata za napako.

http://stackoverflow.com/questions/9029...

Ne drži.

Tale link me ne prepriča. Drugi odgovor sicer omenja tudi "Link-layer CRC" (terminologija je malo samosvoja, ni jasno, a bi radi govorili o Logical Link Control sublayerju, ki se z error-checkingom sploh ne ukvarja (to je naloga MAC sublayerja), verjetno pa je govora o L2), do originalnega članka ne morem dostopat, tisto kar pa lahko preberem, me pa ne navdaja z visoko stopnjo zaupanja v članek:

in one hour-long test we observed a checksum failure of 1 packet in 400

Error-checking imaš vsaj 2x. Če gledamo prenos v lokalnem omrežju, imaš FCS/CRC na Ethernet frameu, simple checksumo pa še v TCP segmentu. Žal ne najdem podatka, ali SMB protokol dela kakršno koli preverjanje, ampak... V statistiki in verjetnosti nisem prav močan, ampak rekel bi, da ko upoštevaš CRC na L2 in še Checksum na L4, verjetnost za pojav nedetektiranih napak pade na blazno nizko?

In za zaključek še enkrat moja trditev: "Kar se tiče TCP/IP bi skoraj rekel, da ga je varno izvzet kot možnega kandidata za napako." Jaz bi preveril vse ostalo prej kot mrežno + tcp/ip stack. Če pa je kriva statistika, se pravi, da je bil OP pač na vrsti za zelo redko napako pri internetnem prenosu, je pa verjetno zelo dolgo ne bo mogel ponoviti.

Še "povzetek", na kratko: nič

Na dolgo:

Naredil 24-urni memtest na obeh računalnikih, enkrat z memtest86+ v5.01 in še enkrat z memtest86 v4.3.7, brez najdenih napak.

badblocks -n na source disku, brez napak.

badblocks (just read način) na vseh diskih: brez napak

SMART short test, long test na ST5000DM : OK
SMART long test na 4 diskih serverja: OK, razen enega, za katerega vem da ima nekaj slabih sektorjev, na neparticioniranem delu diska.

Več kot 20 krat prebran ves disk (vsi štirje na serverju) z md5sum in primerjan rezultat: brez napak

Tudi večkrat naredil enak postopek: kopiranje fajla na server preko CIFS - brez napak

Živjo!

Mi lahko poveste, zakaj pride do razlike v velikosti podatkov pri kopiji? Kako naj bom prepričan, da so vsi podatki intaktni oz. nepoškodovani. Zadnje čase mi tudi prek mreže (rPI NAS - WD Elements - 100 Mbit/s) javlja napake ob inštalacijah pa je lahko preko kabla ali wifi-ja (tega se izogibam, kot hudič križa). Sem že moral menjati oz. dopolniti datoteke.
Nabavil sem si dodatni WD Elements 2 TB, torej identičen model, da imam offline kopijo NAS-a. NAS pa 24/7 prikloplen na mrežo, da lahko sam dostopam in spreminjam podatke, ostali uporabniki pa berejo podatke.



Crystal diskinfo ne kaže problemov, verjetno pa to ni najboljši indikator stanja diskovja, ali pač?

PS: prvi WD Elements 2TB ima za sabo okoli 13k delovnih ur (torej slabi 2 leti), podatkovja je bilo pa zapisanga okoli 5 TB, če sem prav pogledal, torej ne veliko glede na velikost. Pred 3 meseci se je vrhnji pokrov na enem robu 'napihnil' in gleda ven kake 3-5 mm napram preostali površini. Nazaj neče sesti, niti nisem preveč poskušal. Vse še dela, me pa zanima, kaj za vraga je privedlo do tega dogodka.

Hvala!

Kup programov za primerjanje fajlov obstaja.
Recimo KDiff3, če ne najdeš boljšega.