Dotaz: truecrypt a zasekavani

[ZeXx86]

Dobrý den. Před nedávnem jsem instaloval kolegovi Gentoo Linux 2007.0 x86_64 (amd64), kernel ručně kompilovaný, verze 2.6.20-gentoo-r8. Většina věcí mu jede jak má až na jeho zašifrovaný disk. Šifra je ve formátu aes256, jako šifrovací program je použit truecrypt. Oddil ma filesystem ext3 a jeho problém spočívá v tom, že při kopírování dat na zašifrovaný disk z jiného oddílu (taky ext3) ale bez šifry, se pravidelně v 3 sekundovém intervalu zasekává komplet celý kernel, takže i všechno ostatní co jede na pc. Zajímavé ale je, že když kopíruju ze zašifrovaného disku na jiný, tak to jede dobře, naopak ale ne.S tímto problémem jsem se setkal i v ostatních distribucích ale když tam mněl windows, tak mu to jelo bez problému i na ten ext3 oddíl. Věděl by jak to nesnesitelné trhání dát do pořádku ? Kernel do dmesg žádné chyby nevypisuje ani žádný proces nijak nezatěžuje cpu ale stejně se to trhá. Takže nevím co s tím a předem děkuji za každou radu

Odpovědi

[michich]

Zkusil bych tam dát Ingův real-time kernel se zapnutým latency-tracerem. Jestli něco zakazuje přerušení nebo preempci na dlouhou dobu, tak to tracer ukáže.

[-=eM=-]

Ahoj, používám úplně stejnou konfiguraci - bez problému. Není ten disk IDE ? - že by to třeba mohlo být nezapnutým dma. Ten modul truecryptu se mu nahrává během startu ? Dělá to při čtení z toho TC disku, zápisu, nebo obojí ? Případně co čtení raw dat z toho disku bez zavedeného TC ?

[ZeXx86]

Ma 2 IDE disky a 1 SATA. Kdyz kopiruje z ide disku na sata tak se to zasekava, a zjistil jsem, ze pri zaseknuti se spusti proces pdflush ktery bere cca 50-70% cpu a obcas proces kjournald ktery bere kolem 30%. Zjistil jsem ze pdflush ma prave neco spolecneho z disky, vytvori jakesi vlakno a to se stara o to co se nestihlo zapsat pri normalnim kopirovani. A myslim ze tomu pomaha to sifrovani. Kdyz zapl na obou discich udma5 tak ten sek netrva 3s ale uz jen 1-2s. U sata disku nejde nic s dma delat je tam na pevno udma6. Kdyz ze zasifrovaneho sata disku kopiruje na ide, tak to ale neseka vubec a pdflush se nespousti. Jinak nevim jak se da cist raw data, pokud by jste mohl, tak mi to napiste nebo neco co by mi mohlo pomoct, dekuji.

[Shadow]

Raw data se čtou snadno, třeba takto:

dd if=/dev/sda of=/dev/null

Tohle začne číst celý (první SATA) disk (a data putují do černé díry - /dev/null). Lze specifikovat i oddíl:

dd if=/dev/sda1 of=/dev/null

IDE disky (a mechaniky) jsou hda, hdb, apod. A hlavně nepopleťte pořadí if a of.

[Shadow]

Mně se něco podobného také děje, problém se mi povedlo "vyřešit" snížením priority procesu, který data kopíruje, tj. něco jako:

nice -n 19 cp -av zdroj cil

[cthulhu]

resenim tohoto problemu byl v mem pripade (bohuzel az) hw upgrade na dualcore (AMD X2 4800+ misto AMD Sempron 3100+), na jednoprocesorove konfiguraci to melo ty same symptomy. taky aes256, sata disk, ext3..taky sekundove zaseky. u SATA disku abstrahujte od problemu UltraDMA on/off, protoze nic takoveho u nej nastavovat nejde.

[dan1]

Mam to same - distribuce Kubuntu Feisty, zasekavani pri kopirovani na sifrovany disk (tc)

Vypozoroval jsem, ze zasekavani ma na svedomi zurnalovaci proces kjournald. U mne ma vychozi hodnotu nice -5, pokud zmenim prioritu na 0, zasekavani prestane.

Nevite nekdo, kde nastavit, aby se kjournald spoustel s vychozi prioritou 0 ?

Diky, D.