Van egy titkosított partícióm, amely egész jól viselkedik, de tartós I/O - `svn up` egy nagyobb forrás ágon - esetén a kcryptd felzabálja az erőforrásokat és az I/O-t igénylő műveletek több másodpercig állnak és várnak a sorukra. Az `iotop` kimenetén ez látszik:
PID USER DISK READ DISK WRITE SWAPIN IO> COMMAND
965 root 0 B/s 0 B/s 0.00 % 99.99 % [kcryptd]
Az `iostat` szerint sem történik nagy mértékű I/O forgalom, a `top` pedig 0% CPU használatot ír a kcryptd futásához, ám a TIME+ oszlopon látni lehet, hogy az `svn up` parancs és az azt követő I/O idejéig kizárólag a kcryptd kapta meg a CPU-t:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
965 root 15 -5 0 0 0 S 15 0.0 10:20.21 kcryptd
...
965 root 15 -5 0 0 0 S 1 0.0 10:24.34 kcryptd
Nem okozna különösebb gondot ez, ha a magas I/O terhelés ideéig nem állna meg a többi program futása, ugyanis amelyik program I/O-t igényel, az vár egészen addig, amíg a kcryptd be nem fejezi az ámokfutást.
A titkosított partíció:
$ cryptsetup status cryptedPart3
/dev/mapper/cryptedPart3 is active:
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/sdb3
offset: 2056 sectors
size: 37895279 sectors
mode: read/write
Nálatok megy rendesen? :)
- 1056 megtekintés
Hozzászólások
Úgy látom ez régi issue... :)
http://lkml.org/lkml/2006/2/1/355
Nekem is a sok apró fájl a probléma, egy bonnie++ futása mellett - ha nem is olyan reakcióidővel, mint normál esetben, de lehet dolgozni. A kjournald fut többet, a kcryptd nem igazán dolgozik.
Arra tudok gondolni, hogy a kcryptd-nek minden apró módosítás miatt egy egész blokkot vagy blokkokat kell ki és be titkosítania és ez okozza a terhelést.
--
http://wiki.javaforum.hu/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni