Lazán kapcsolódik: amíg a diszket kcryptd-n keresztül érjük el (titkosított partíció vagy LVM PV), addig tök mindegy. A kcryptd összemossa az összes IO kérést egyetlen folyamba, és az alatta lévő blokkütemező egyetlen forrásból (= kcryptd-ből) érkezőként lát mindent. Vagyis lényegtelen, milyen ütemezőt választunk, olyan, mint ha nem is lenne.
Sajnos ez egy borzasztóan idegesítő hiba. Példa: tegyük fel, hogy 10 percenként egyszer fut egy recollindex, vagy akármilyen program, amely szétszórva ír egy csomó kicsi blokkot, majd a végén kitol egy nagy fsync()-et. Ha ez ugyanazon a fizikai diszken (nem filesystem-en!) történik, mint ahol interaktív munkát végzünk, és mindkét jellegű hozzáférés átmegy a kcryptd-n valamilyen rétegben, akkor az interaktív munkánkban 6-13 másodperces fagyásokat is tapasztalhatunk. Lényegében amíg az fsync() fut az X processz kedvéért, addig az összes többi processz is fennakad, amelyik lapozásra kényszerül. Ez nyilván abszurd.
Ha jól tudom, dolgoznak a fiúk, hogy a kcryptd továbbpasszolja az eredeti kontextust az ütemezőnek (vagy valami más trükkön), de még csak kísérleti fázisban van.