Stažené soubory s nesedícím md5

Re:Stažené soubory s nesedícím md5
« Odpověď #45 kdy: 24. 06. 2025, 09:29:11 »
S vyloučením vlivu je to komplikovanější. Jendou jsem takto řešil náhodné restarty. Zkoušel jsem jiný zdroj, jinou MoBo a další. Nic nepomáhalo, indicie směřovaly k SSD a GPU (společný jmenovatel je napájení a PCIe komunikace, proti zdroj MoBo, a zvažoval jsem i CPU), pořád se nedařilo odhalit příčinu. Nakonec byl problém jak v SSD, tak v GPU. Někdy se prostě sejde více vadných věcí.


Re:Stažené soubory s nesedícím md5
« Odpověď #46 kdy: 24. 06. 2025, 09:29:30 »
- na diff se chystám, ale ten nám přece řekne, kde je chyba v souboru, ne? A vzhledem k tomu, že každý ze stažených souborů (teď už jich mám asi 12) má jiný checksum, nevím, jestli nám to něco pomůže
Pomůže. Třeba když bude chyba na tom samém místě, kde se přerušilo stahování. Nebo bude vždy na stejném místě. Nebo bude chyba spočívat v tom, že tam budou jen nulové bajty.

Pořád jste také ještě neudělal test, zda při opakovaném čtení (s vytlačením z cache) vychází stejný otisk nebo jiný. Takže nevíme, zda k chybě dochází při zápisu či při něm a data jsou už na disku chybně zapsané, nebo zda k chybě dochází až během čtení.

RDa

  • *****
  • 3 059
    • Zobrazit profil
    • E-mail
Re:Stažené soubory s nesedícím md5
« Odpověď #47 kdy: 24. 06. 2025, 19:16:12 »
- na diff se chystám, ale ten nám přece řekne, kde je chyba v souboru, ne? A vzhledem k tomu, že každý ze stažených souborů (teď už jich mám asi 12) má jiný checksum, nevím, jestli nám to něco pomůže

Idealne tedy vice diffu, vuci OK souboru.

Tech chyb tam muze byt vicero - 1 bit flip v podobne nebo nahodne lokaci, kus opakovanych dat, blok zcela random dat, nejaka nulova oblast .. a to vse dava indice kde problem hledat.

Kdyz nevime detaily chyb, jen ze soubor je jiny.. tak je vysledek.. mas to rozbity a kup si novej komp.

Pokud pocitac jinak nepada, tak bych treba vadnou RAM vyloucil. Protoze pokud hitnete stahovani dat s chybou, tak by vam ty appky padali viditelne jako hnile hrusky na segfault.

Za me je k dalsimu hledani chyby (tj. vetveni - je to sitovka nebo je to disk) by pomohlo kdyby jste data na obou koncich spoje (jestli je mate tedy ve vlastni rezii) ukladal/stahoval/sdilel pouze z ramdisku (tj /dev/shm ). To pak rekne zda to je disk nebo sitovka. (za me sit/sitovka je pravdepodobnejsi, protoze chybnej disk by se taky projevil segfaultama aplikaci).

Re:Stažené soubory s nesedícím md5
« Odpověď #48 kdy: 24. 06. 2025, 20:47:53 »
Za me je k dalsimu hledani chyby (tj. vetveni - je to sitovka nebo je to disk) by pomohlo kdyby jste data na obou koncich spoje (jestli je mate tedy ve vlastni rezii) ukladal/stahoval/sdilel pouze z ramdisku (tj /dev/shm ). To pak rekne zda to je disk nebo sitovka. (za me sit/sitovka je pravdepodobnejsi, protoze chybnej disk by se taky projevil segfaultama aplikaci).

Síťovka mi přijde jako fakt nepravděpodobná, jak už jsem tu jednou psal. SSH, které mu předtím při přenosech blblo taky, má MAC. Stačí jediný bitflip ve zprávě po cestě a rozpadne se ti spojení. Na TCP hlavičkách máš taky CRC.
Tzn. pokud bez viditelné chyby a zastavení přenosu projde přes SCP/SFTP soubor, tak už je porušená integrita souboru,  co se načítá z disku (resp. zapisuje při obráceném směru přenosu).

@DrFreeze

Takže můj tip je disk nebo něco souvisejícího. Na stranu druhou mi přijde že, pokud by to četlo a zapisovalo s chybami všechno (tzn. i / resp. /var oddíl), nejspíš by začaly také náhodně padat programy a systém.
Další věc, co mě trochu zaráží, že by opravdu nikde nebyla ani jedna hláška nebo indicie (dmesg, žurnál, filesystém, vzrůstající SMART countery u disků s CRC chybami...).

Opravdu bych zkusil to fio (mělo by to být v balíčcích)
Dá se to ozkoušet na různé disky, případně i do /tmp, který bývá tmpfs (ramdisk, můžete ověřit v /proc/mounts).

Nejdřív s jednoduchým patternem, kde se dobře hledá. Jakmile to nepřečte správně, skončí to chybou. Když pak odeberete verify_fatal=1 v prvním kroku, zapíše vždy celou velikost, což se hodí třeba na následnou analýzu.


# zapis+verifikace
fio --name=write --filename=testfile --rw=write --size=1G --bs=4k \
    --direct=1 --ioengine=libaio --verify=pattern --verify_pattern=0xDEADBEEF --verify_fatal=1

# samostatna verifikace
fio --name=verify --filename=testfile --rw=read --bs=4k \
    --direct=1 --ioengine=libaio --verify=pattern --verify_pattern=0xDEADBEEF --verify_fatal=1

# kontrola zapsaneho souboru hexdumpem (skipuje vsechny opakujici se radky, takze je hned videt chyba)
hexdump -C testfile
00000000  de ad be ef de ad be ef  de ad be ef de ad be ef  |................|
*
40000000


Případně ve stejném duchu zápis náhodných dat plus crc verifikace.

# zapis s vlozenym crc kodem a verifikace
fio --name=crcwrite --filename=testfile2 --rw=write --size=1G --bs=4k \
   --direct=1 --ioengine=libaio --verify=crc32c --verify_interval=4k --verify_fatal=1

# samostatna verifikace crc
fio --name=crcverify --filename=testfile2 --rw=read --bs=4k \
   --direct=1 --ioengine=libaio --verify=crc32c --verify_interval=4k --verify_fatal=1


Tohle se dá vesele opakovat s různými disky, oddíly po změnách konfigurace atp. Také s tím patternem můžete snadno zjistit, co se tam případně rozbíjí, jestli je to náhodné atp.

Re:Stažené soubory s nesedícím md5
« Odpověď #49 kdy: 24. 06. 2025, 20:57:30 »
- na diff se chystám, ale ten nám přece řekne, kde je chyba v souboru, ne? A vzhledem k tomu, že každý ze stažených souborů (teď už jich mám asi 12) má jiný checksum, nevím, jestli nám to něco pomůže
Pokud pocitac jinak nepada, tak bych treba vadnou RAM vyloucil. Protoze pokud hitnete stahovani dat s chybou, tak by vam ty appky padali viditelne jako hnile hrusky na segfault, [...] protoze chybnej disk by se taky projevil segfaultama aplikaci).

To není ani náhodou jisté. Zcela nedávno jsem řešil, že mi v notebooku odešel jeden modul RAM. Shodou okolností horních 16 GB. Projevovalo se to tak, že dokud nebyl spodní modul plný, aplikace nepadaly, alokovaly evidentně zespodu adresního prostoru. A neprojevovalo se to ani na diskové cache protože ta se také udržela ve spodní části paměťi. Jakmile ale došlo k zaplnění, aplikace se postupně jednak staly nestabilní a druhak začaly sem tam vznikat chyby ve filesystému kvůli diskové cache v té vadné horní polovině adresního prostoru, odkud občas přišly chybné bajty.

Celé jsem to odhalil až asi za měsíc a to jsem ten notebook intenzivně používal denně. Do té doby se to projevovalo tak, že sem tam občas prostě něco spadlo (typicky prohlížeč, ten je paměťově náročný) a občas byl poškozený filesystém. Od výměny selhávajícího modulu je vše OK. Takže na ty segfaulty bych se nutně fakt nespoléhal. Problém klidně může být třeba v konkrétním úzkém adresovém bloku paměťi využívaném pro DMA. Nebo třeba v IOMMU. Nebo kdekoliv mezitím.


Re:Stažené soubory s nesedícím md5
« Odpověď #50 kdy: 24. 06. 2025, 21:01:15 »
Tak zas s vadnou RAM by se ten výskyt chyby pravděpodobně neměnil podle toho kolik je tam zapojených disků, jak tazatel píše.

Re:Stažené soubory s nesedícím md5
« Odpověď #51 kdy: 25. 06. 2025, 08:41:25 »
mam zcela identickou zkusenost. jen to bylo hornich 32 GB. dokud jsem nezkusil memtest, tak jsem  neveril, ze je to pameti.
kde jsou stare dobre casy paritnich pameti


 
- na diff se chystám, ale ten nám přece řekne, kde je chyba v souboru, ne? A vzhledem k tomu, že každý ze stažených souborů (teď už jich mám asi 12) má jiný checksum, nevím, jestli nám to něco pomůže
Pokud pocitac jinak nepada, tak bych treba vadnou RAM vyloucil. Protoze pokud hitnete stahovani dat s chybou, tak by vam ty appky padali viditelne jako hnile hrusky na segfault, [...] protoze chybnej disk by se taky projevil segfaultama aplikaci).

To není ani náhodou jisté. Zcela nedávno jsem řešil, že mi v notebooku odešel jeden modul RAM. Shodou okolností horních 16 GB. Projevovalo se to tak, že dokud nebyl spodní modul plný, aplikace nepadaly, alokovaly evidentně zespodu adresního prostoru. A neprojevovalo se to ani na diskové cache protože ta se také udržela ve spodní části paměťi. Jakmile ale došlo k zaplnění, aplikace se postupně jednak staly nestabilní a druhak začaly sem tam vznikat chyby ve filesystému kvůli diskové cache v té vadné horní polovině adresního prostoru, odkud občas přišly chybné bajty.

Celé jsem to odhalil až asi za měsíc a to jsem ten notebook intenzivně používal denně. Do té doby se to projevovalo tak, že sem tam občas prostě něco spadlo (typicky prohlížeč, ten je paměťově náročný) a občas byl poškozený filesystém. Od výměny selhávajícího modulu je vše OK. Takže na ty segfaulty bych se nutně fakt nespoléhal. Problém klidně může být třeba v konkrétním úzkém adresovém bloku paměťi využívaném pro DMA. Nebo třeba v IOMMU. Nebo kdekoliv mezitím.

JmJ

  • ****
  • 333
    • Zobrazit profil
Re:Stažené soubory s nesedícím md5
« Odpověď #52 kdy: 25. 06. 2025, 08:43:47 »
Neprocital sem cele tema, takze reaguju uplne na prvni dotaz.

Pred cca 2 lety sem resil na vice jak 10 let starem hw s debianem, ze rsync na velkych souborech nespocital spravne crc.

Menil sem disk, pamet, cpu, sitovou kartu, cistou instalaci atd, jedine co zustavalo byl motherboard. Nechal sem puvodni instalaci debianu, disky a vymenil stary hw a problem zmizel. Takze bud se neco v debianu nekamaradilo s tim hw nebo ten hw po vice jak 10 letech nepracoval dobre.

Re:Stažené soubory s nesedícím md5
« Odpověď #53 kdy: 25. 06. 2025, 09:58:59 »
Slibuju, že dnes si zkusím vyhradit čas na pořádně provedený diff :-)

Včera jsem vzal všechny tři disky a zkusil nabootovat na desce s Intelem G550, ale jak jsem později zjistil, bez opravy/modifikace Grubu to nepůjde ("Select proper boot device", zkoušeno UEFI i legaci, IDE i AHCI). Už jsem si kolem toho něco našel, ale nejdřív potrápím ten diff.

Re:Stažené soubory s nesedícím md5
« Odpověď #54 kdy: 25. 06. 2025, 17:52:15 »
Takže:
- stažení souboru tentokrát hlásilo (jen) dvě chyby.
- když jsem chybně pustil hexdump tak, že to vypisoval do stdout, připojení přes ssh padlo
- převedl jsem OK a nOK soubory do ASCII (velikost přes 1,2 GB) a když jsem na serveru na ně pustil diff, taky spadl
- překopíroval jsem nOK soubor na notebook (musel jsem přes flash, protože přes scp měl pak jiný checksum než původně), zkontroloval checksum, aby byl na původním disku, na flash i na ntb shodný
- na ntb převedeno do ASCII a diff hlásí asi třicet rozdílů - předpokládám, že nemá cenu to porovnávat s offsetem, na kterém padlo stahování (mám zaznamenáno)
- na závěr jsem se pokusil vystresovat CPU hexdumpem a paralelně pustit wget: tentokrát hlásí 8 chyb

V pátek se dostanu zase na ten počítač, kde bych to mohl vyzkoušet, jen si musím najít, jak rekonfigurovat Grub.

Re:Stažené soubory s nesedícím md5
« Odpověď #55 kdy: 25. 06. 2025, 18:21:56 »
To musí bejt lábuž ten šrot používat a týdny pátrat, to se fakt vyplatí. Hoď ten krám do popelnice.

jjrsk

  • *****
  • 785
    • Zobrazit profil
Re:Stažené soubory s nesedícím md5
« Odpověď #56 kdy: 26. 06. 2025, 08:02:43 »
To by do ty popelnice musel nahazet vsechno ... zrovna tu mam uplne novej NB s uplne novym USB dockem ... a sitovka se chova opravdu zajimave ... na tri adresy si pingnes, na 4tou ne ... kdyz to restartnes, tak si pingnes na tu ctvrtou, ale ne jednu z tech 3 ne. ...


Re:Stažené soubory s nesedícím md5
« Odpověď #57 kdy: 26. 06. 2025, 13:46:49 »
Ono to samozřejmě všechno ukazuje na výměnu desky. Zvlášť když jsem včera upgradoval BIOS a od té chvíle se deska nezná k diskům připojeným na přídavný miniPCIe řadič :-)

Co se výkonu týká, tak stávající Celer J1800 sice není žádný rychlík, ale na občasnou zálohu z PC a mobilu do Nextcloudu nebo občasnou nahrávku z TV tuneru (tvheadend) stačí levou zadní. Takže kandidát na upgrade je např. tento:
https://www.tsbohemia.cz/gigabyte-n4120i-h_d528800

Re:Stažené soubory s nesedícím md5
« Odpověď #58 kdy: 01. 08. 2025, 16:02:11 »
MD5 se dávno nepoužívá. Podívej se na články zde na rootu od Klímy, Vondrušky a Rosy. Je to už 25 let pasé. Dnes pouze SHA-3.

Re:Stažené soubory s nesedícím md5
« Odpověď #59 kdy: 01. 08. 2025, 16:32:54 »
Záleží na účelu.
Tam kde jde o bezpečnost (hashe hesel) máte pravdu.
Ale tam, kde jde jen o technickou kontrolu shody/neshody dvou souborů, se pořád běžně používá (jako alternativa CRC32).