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…)