Podivné kopírování mezi dvěma NVMe disky

[Feňák]

Mám v počítači dva M2 disky, oboje nějaký Samsung 970 EVO. Mám z internetu staženou část ZIP archivu, na kterou, když spustim příkaz

Kód: [Vybrat]

7z t file.package.001, tak je vše v pořádku a objeví se mi "Everything is OK". Utilitou "cp" si ji zkopíruju na druhý disk. Vše proběhne v pořádku, ale když na tom druhém disku opět ověřím stejným příkazem ten zkopírovaný soubor, skočí to chybou a hláškou "ERROR: CRC Failed : fs-base-cgl/CGL/112/dem211.cgl". Provedu to samé kopírování třeba ještě dvakrát a na třetí pokus mi najednou 7z hlásí "Everything is OK" i u toho zkopírovaného souboru. Jak je to možné? To se nelze spolehnout na prosté kopírování mezi disky? Kdyby alespoň "cp" zahlásil nějakou chybu, ale on ne. Musím tedy při každém kopírování ověřit, jestli se zkopírovaly všechny bajty a je to otravné. Čím myslíte, že by to mohlo být? Cílový M2 disk je asi 6 let starý, zdrojový je starý rok.

[Reklama]

[k3dAR]

Jen si tipnu, mas problemove Samsungy a moc stary ci novy ci spatny FW (alespon v 1 nvme), to v kterem zkus overit kopirovanim do ram (coz mas cestu /dev/shm) a overeni tam...

Samsung je dlohodobe znam problemama v Linuxu, kdy Linux jadro dokola pridava nove a nove workaroundy aby ty chyby obesel...

[Václav Ovsik]

Asi bych v první řadě začal hledat, kde se data liší. Pokud se to opravdu liší, tak je to celkem průšvih. Co nějaké zkoumání disku přes utilitu nvme? (device-self-test, self-test-log...)

[Feňák]

Jen si tipnu, mas problemove Samsungy a moc stary ci novy ci spatny FW (alespon v 1 nvme), to v kterem zkus overit kopirovanim do ram (coz mas cestu /dev/shm) a overeni tam...

Samsung je dlohodobe znam problemama v Linuxu, kdy Linux jadro dokola pridava nove a nove workaroundy aby ty chyby obesel...

Tak jsem zkoušel různé pokusy s kopírováním do /dev/shm a mám poznatek. Vše funguje úplně na výbornou. Udělal jsem několik stovek testů s kopírováním jednoho, necelých 1GB, souboru. Z obou disků.

Posunulo mě to dál, protože potom jsem spustil Steam a v něm Microsoft Flight Simulátor (z něj je ten velký soubor). Test jsem znovu spustil a přibližně 10% kopií mělo CRC chybu. Vypnul jsem Steam a opět všechny soubory se zkopírovaly bez jakékoliv chyby. Problém bych tedy neviděl v discích, ale v něčem, co může ovlivňovat zápis na ně.

Kdybyste měli ještě nějaké tipy, byl bych rád. Zatím budu pátrat, co MFS ovlivňuje v systému, když je spuštěný.

[Vít Šesták (v6ak)]

Napadá mě otestovat RAM. Data z SSD půjdou z/do RAM. A spuštění nějakého programu může znamenat, že se zdravá část RAM použije na jiný účel.

[Reklama]

[Václav Ovsik]

Problém při souběžném používání disku by mohl ukazovat na ten problem s firmwarem. Možná se zkusit podívat jak u disku NVME vypnout některé featury parametrem jádra. Zkusit to parametry nastavit do co nejtupějšího režimu a opakovat experiment s kopírováním...

[NaRootuJeNeskutecneDebilniRegistracniFormular]

Ja bych vsadil na spatnou RAM.

[jjrsk]

Ja bych vsadil na spatnou RAM.

To by mu crashoval celej stroj a ne jen kopirovani. Videl bych to na ty disky. Nebo jeden z nich. A jelikoz dotycny nerika nic k tomu jak je pouziva, predpokladam, ze jeden je systemovy, a jelikoz system asi nepada, tak failovat bude ten druhy.

Jeste pripada v uvahu alternativa ta, ze ty disky blbe sdilej pci-e s necim dalsim, coz by sice vadit nemelo, ale ... jen dost pochybuju, ze se stim da neco udelat. Vyzkousel bych oba v jinym MB.

[RDa]

Ja bych vsadil na spatnou RAM.

Ramkou to na 100% neni. To by mel BSOD co chvili.. on ma jenom spatna data na disku. Takze problem tech SSD.

Dalo by se to jeste odladit, zda to delaj oba, nebo jenom jeden - pri kopirovani na ramdisk/treti medium po jednom.

Existuji tooly, ktere umi vicevlaknove kopirovani - tak bych toho vyuzil.

Preventivne muzes vypnout ASPM v biosu, ale nevim zda mas moznost menit queue depth za behu..

.. ale jak uz nekdo zminil, jestli to je FW chyba, tak muzes zacit zalohou a pak upgrade fw pres Samsung Magician.

[Vít Šesták (v6ak)]

Těžko říct:

1. Z popisu nevím, jestli pozoruje i jiné problémy.
2. Pokud to vyjde tak, že aplikace a OS jsou v dobré části RAM, nemusí nic zlobit. A u kernelu je celkem realistické, že se problematické části RAM vyhne.
3. Na druhou stranu, pokud zlobí zápis nebo čtení na SSD, dříve či později čekám padání aplikací či OS. Takže tímto to od vadné RAM neodlišíme.

Jinak ano, zjištění, jestli zlobí obě SSD, může taky dát podstatnou informaci, jestli bude problém v SSD, nebo jinde. (Ano, Murphyho zákon říká, že budou obě SSD vadná, a člověk bude hledat problém jinde. Už se mi něco podobného stalo…)

[Feňák]

Rano jsem zkousel kopirovat na plotnovy externi disk. Nejdriv to vypadalo slibne, ale pak jsem zacal pozorovat chyby. Zajimave bylo, ze to, co jsem zkontroloval na externim disku, bylo po zkopirovani dalsich X GB zase rozbite. Nainstaloval jsem memtest64+ a zkontroloval vsechny 4 32GB RAMky. Ty starsi 2 hlasily nejake chyby uz u testu #2. Dokontroluju ty mladsi a zkusim nechat v dualchannelu jen ty dve novejsi, bez erroru. A uvidime, co se stane pri tom kopirovani. RAM muze mit vliv na operace s diskem, ne?

Jeste pro upresneni dodam, ze obcas mi spadnul Gradle pri kompilaci. Pomohlo nastavit max. vyuziti RAM na 50%, pak to uz nepadalo. S padanim OS problem nikdy nebyl. Obcas mi vytuhla graficka karta a shodily se Xka, to ale az poslednich 14 dni, co jsem poridil novou grafiku (thread k tomu je v sekci Desktop tady na Rootu).

[Vít Šesták (v6ak)]

Vadná RAM může být dost nevyzpytatelná. Nemusí nutně být vadná celá, a pak je to loterie, co se trefí do vadné části. Navíc problém se nemusí projevit pokaždé.

Kernel je celkem malý, a sám o sobě asi nepotřebuje kdoví kolik RAM pro data (nepočítám aplikace a cache), takže kernel panic nemusí nastávat, nebo jen zřídka.

Ano, čtení a zápis půjde přes RAM, a může být ovlivněn vadnou RAM. Pamatuju si, jak při vadné RAM mi při stahování opakovaně neseděl hash, a to pokaždé jinak.

Skoro bych se vsadil, že bez té vadné RAM to už pojede dobře.

Nová grafika je s otazníkem. Může to být náhoda (RAM se pokazila v nevhodnou dobu), může to znamenat, že najednou driver využívá jiné části RAM, a něco se trefí do té vadné.

[NaRootuJeNeskutecneDebilniRegistracniFormular]

Ja bych vsadil na spatnou RAM.

Ramkou to na 100% neni. To by mel BSOD co chvili.. on ma jenom spatna data na disku. Takze problem tech SSD.

Ehm.

[Rovano _]

Tak pokud je to jen RAM, tak to máš dobré a hurá padla.

Vadná RAM se samozřejmě nemusí nikdy ani odhalit a nečemu zdánlivě vadit. V nejhorší nouzi se dá kernel nastavit, ať část nevyužívá.

Nemohla by to být jen nekompatibilita těch dvou sad modulů? Otestoval bych je sólo.

[Feňák]

Nemohla by to být jen nekompatibilita těch dvou sad modulů? Otestoval bych je sólo.

Zkusím, ale nemyslím si. Všechny jsou úplně stejné, stejný výrobce, stejný typ, stejné časování. Liší se jen rokem výroby. Ty starší maj na sobě "2020 November" a ty novější "2021 October".