Abysmal genel dm-crypt (LUKS) yazma performansı

Bir blok cihazını şifrelemenin yazarken büyük bir performans cezası getirdiği bir sorunu araştırıyorum . Saatler süren Internet okuma ve deneyler bana bir çözüm değil, doğru bir anlayış sağlamıyordu.

Kısacası soru: Neden bir blok cihaza btrfs takarken (~ 170MB / s) mükemmel bir yazma hızına sahip oluyorum; dosya sistemi ve blok aygıtı, sistem yeterince yüksek bir şifreleme verimini sürdürebilmekten daha fazlası olmasına rağmen?

senaryo

/home/schlimmchen/random/dev/urandomönceki verilerle dolu bir 4.0 GB dosyadır .

dd if=/dev/urandom of=/home/schlimmchen/Documents/random bs=1M count=4096

Okumak süper hızlı:

$ dd if=/home/schlimmchen/Documents/random of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 6.58036 s, 648 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 0.786102 s, 5.4 GB/s

(ikinci kez, dosya açıkça önbellekten okundu).

Şifrelenmemiş btrfs

Cihaz doğrudan btrfs ile biçimlendirilmiştir (blok cihazda bölüm tablosu yoktur).

$ sudo mkfs.btrfs /dev/sdf
$ sudo mount /dev/sdf /mnt
$ sudo chmod 777 /mnt

Yazma hızı ~ 170MB / s'ye kadar yükseliyor:

$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 27.1564 s, 157 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test2 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 25.1882 s, 169 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test3 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 29.8419 s, 143 MB/s

Okuma hızı 200 MB / sn'nin oldukça üstünde.

$ dd if=/mnt/dd-test1 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.8265 s, 215 MB/s
$ dd if=/mnt/dd-test2 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.9821 s, 213 MB/s
$ dd if=/mnt/dd-test3 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 19.8561 s, 215 MB/s

Blok cihazda şifreli btrfs

Aygıt LUKS ile biçimlendirilmiş ve sonuçta elde edilen aygıt btrfs ile biçimlendirilmiştir:

$ sudo cryptsetup luksFormat /dev/sdf
$ sudo cryptsetup luksOpen /dev/sdf crypt
$ sudo mkfs.btrfs /dev/mapper/crypt
$ sudo mount /dev/mapper/crypt /mnt
$ sudo chmod 777 /mnt
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 210.42 s, 20.3 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test2 bs=1M 
4265841146 bytes (4.3 GB) copied, 207.402 s, 20.6 MB/s

Okuma hızı yalnızca marjinal olarak zarar görüyor (neden hiç yok?):

$ dd if=/mnt/dd-test1 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 22.2002 s, 192 MB/s
$ dd if=/mnt/dd-test2 of=/dev/null bs=1M
4265841146 bytes (4.3 GB) copied, 22.0794 s, 193 MB/s

luksDump: http://pastebin.com/i9VYRR0p

Şifreli btrfs blok cihazındaki btrfs dosyasında

Şifrelenmiş bir dosyaya yazarken yazma hızı "yüksek hıza" çıkar. Blok cihaza bir btrfs koydum, yerleştirdiğim ve yerleştirdiğim bir 16GB dosya lukfsFormatayırdım.

$ sudo mkfs.btrfs /dev/sdf -f
$ sudo mount /dev/sdf /mnt
$ sudo chmod 777 /mnt
$ dd if=/dev/zero of=/mnt/crypted-file bs=1M count=16384 conv=fsync
17179869184 bytes (17 GB) copied, 100.534 s, 171 MB/s
$ sudo cryptsetup luksFormat /mnt/crypted-file
$ sudo cryptsetup luksOpen /mnt/crypted-file crypt
$ sudo mkfs.btrfs /dev/mapper/crypt
$ sudo mount /dev/mapper/crypt /tmp/nested/
$ dd if=/home/schlimmchen/Documents/random of=/tmp/nested/dd-test1 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 26.4524 s, 161 MB/s
$ dd if=/home/schlimmchen/Documents/random of=/tmp/nested/dd-test2 bs=1M conv=fsync
4265841146 bytes (4.3 GB) copied, 27.5601 s, 155 MB/s

Yazma performansı neden böyle artmaktadır? Bu belirli dosya sistemlerini ve blok aygıtlarını yerleştirme yüksek yazma hızlarında yardımcı olmak için neler sağlar?

Kurmak

Sorun, aynı dağıtımı ve çekirdeği çalıştıran iki sistemde tekrarlanabilir. Ancak, düşük yazma hızlarını da System2'de çekirdek 3.19.0 ile gözlemledim.

• Cihaz: SanDisk Extreme 64GB USB3.0 USB Stick
• Sistem1: Intel NUC 5i5RYH, i5-5250U (Broadwell), 8 GB RAM, Samsung 840 EVO 250 GB SSD
• Sistem2: Lenovo T440p, i5-4300M (Haswell), 16GB RAM, Samsung 850 PRO 256GB SSD
• Distro / Çekirdek: Debian Jessie, 3.16.7
• cryptsetup: 1.6.6
• /proc/cryptoSistem1 için: http://pastebin.com/QUSGMfiS
• cryptsetup benchmarkSistem1 için: http://pastebin.com/4RxzPFeT
• btrfs (-tools) sürüm 3.17
• lsblk -t /dev/sdf: http://pastebin.com/nv49tYWc

Düşünceler

• Uyum, görebildiğim kadarıyla sebep değil . Çubuğun sayfa boyutu 16KiB olsa bile, kripto kurulum yükü başlangıcı yine de 2MiB'ye hizalanır.
• --allow-discards (cryptsetup's luksOpen için) beklediğim gibi, yardımcı olmadı.
• Onunla çok daha az deney yaparken, USB3.0 bağdaştırıcısına bağlı harici bir sabit diskle çok benzer davranışlar gözlemledim.
• Bana öyle geliyor ki, sistem 64 KBB blok yazıyor. Çalıştığım bir systemtrap betiği en azından bunu gösteriyor. /sys/block/sdf/statBirçok hipotez birleştiğinden bu hipotezi desteklemektedir. Yani benim tahminim, çok küçük bloklar halinde yazmanın nedeni değil.
• Engelleme aygıtı sıra zamanlayıcısını NOOP olarak değiştirmede şans yok.
• Şifreyi bir LVM birime koymak yardımcı olmadı.

Cevap (şimdi bildiğim gibi): eşzamanlılık .

Kısacası : Bir dosyayı kopyalarken ya da kullanırken ( sırayladd ... gibi) sıralı yazım , sözde rastgele yazma (kötü) olur, çünkü dört iş parçacığı, şifreli verileri eşzamanlı olarak blok cihazına aynı anda yazarken çalışıyor şifreleme (iyi).

Azaltma ("daha eski" çekirdekleri için)

Olumsuz etki aşağıdaki gibi IO zamanlayıcı sırasındaki sıralı isteklerin miktarını artırarak azaltılabilir:

echo 4096 | sudo tee /sys/block/sdc/queue/nr_requests

Benim durumumda bu, sorumla açıklanan 4GB'lık rasgele veri testinin verimini üçe (~ 56MB / sn) çıkardı. Tabii ki, performans hala şifrelenmemiş IO'ya kıyasla 100 MB / sn düşüyor.

soruşturma

Çok çekirdekli blktrace

Bir LUKS şifreli blok cihazının üstüne bir btrfs'nin yerleştirildiği sorunlu senaryoyu daha da araştırdım. Gerçek blok aygıtına hangi yazma talimatlarının verildiğini göstermek için, şöyle kullandım blktrace:

sudo blktrace -a write -d /dev/sdc -o - | blkparse -b 1 -i - | grep -w D

Bunun ne olduğunu (anlayabildiğim kadarıyla) /dev/sdc" yazma " tipinde olan IO talebini izleme , daha sonra bunu insan tarafından okunabilir çıktıya ayırma, ancak çıktıyı ( D'ye göre man blkparse) olan " D " eylemiyle sınırlama Msgstr " IO sürücüye verildi ".

Sonuç, bunun gibi bir şeydi ( çok çekirdekli logun yaklaşık 5000 satırlık çıktı satırına bakın ):

8,32   0    32732   127.148240056     3  D   W 38036976 + 240 [ksoftirqd/0]
8,32   0    32734   127.149958221     3  D   W 38038176 + 240 [ksoftirqd/0]
8,32   0    32736   127.160257521     3  D   W 38038416 + 240 [ksoftirqd/0]
8,32   1    30264   127.186905632    13  D   W 35712032 + 240 [ksoftirqd/1]
8,32   1    30266   127.196561599    13  D   W 35712272 + 240 [ksoftirqd/1]
8,32   1    30268   127.209431760    13  D   W 35713872 + 240 [ksoftirqd/1]

• Sütun 1: büyük, blok aygıtının küçük
• Sütun 2: CPU Kimliği
• Sütun 3: sıra numarası
• Sütun 4: zaman damgası
• Sütun 5: işlem kimliği
• Sütun 6: eylem
• Sütun 7: RWBS verileri (tür, sektör, uzunluk)

Bu, dd4GB rasgele veriyi monte edilmiş dosya sistemine taşırken üretilen çıktının bir parçası . En az iki sürecin dahil olduğu açıktır. Kalan kütük dört işlemcinin hepsinin üzerinde çalıştığını gösteriyor. Ne yazık ki, artık yazma istekleri sıralı değil. CPU0, 38038416. sektörün etrafında bir yere yazarken, daha sonra programlanan CPU1, 35713872. sektörünün etrafında bir yere yazıyor. Bu kötü.

Tek çekirdek blktrace

Aynı işlemi çoklu iş parçacığını devre dışı bıraktıktan ve işlemcimin ikinci çekirdeğini devre dışı bıraktıktan sonra yaptım. Elbette, çubuğa yazı yazarken sadece bir işlemci var. Fakat daha da önemlisi, yazma talebi düzgün bir şekilde sıralıdır, bu yüzden ~ 170MB / s'nin tam yazma performansına, aksi takdirde aynı kurulumda ulaşılır.

Tek çekirdekli kütükteki yaklaşık 5000 satırlık çıktıya bir göz atın .

Tartışma

Nedenini ve uygun google arama terimlerini bildiğime göre, bu sorunla ilgili bilgiler yüzeye çıkıyor. Görünen o ki, ilk farkeden ben değilim.

• Dört yıl önce, bir yama çok çekirdekli dm-crypt'u çekirdeğe getirdi . Bu kesin olarak benim bulgularıma tam olarak uyuyor.
• İki yıl önce yamalar , yazma isteklerinin yeniden sıralanması da dahil olmak üzere dm-crypt performansını iyileştirdi .
• Bir yıl önce, konu hala tartışıldı .
• Son zamanlarda, dm-crypt için sıralama sağlayan bir yama nihayet çekirdeğe bağlandı.
• Bir yoktur ilginç e-posta bu olgunun ilişkin (Çok ait okumadım) performans testleri ile.

Geçerli çekirdeklerde düzeltildi (> = 4.0.2)

Çünkü ben (daha sonra) bu kesin problemi hedef alan çekirdek taahhüdünü açıkça bulduğum için , güncellenmiş bir çekirdeği denemek istedim. [Kendim derledikten ve daha sonra içinde olduğunu öğrendikten sonra debian/sid] Sorunun gerçekten çözüldüğü ortaya çıktı. Düzeltmenin göründüğü tam çekirdek sürümü bilmiyorum ama orijinali ilgilenen kimseye ipucu verecek.

Kayıt için:

$ uname -a
Linux t440p 4.0.0-1-amd64 #1 SMP Debian 4.0.2-1 (2015-05-11) x86_64 GNU/Linux
$ dd if=/home/schlimmchen/Documents/random of=/mnt/dd-test bs=1M conv=fsync
4294967296 bytes (4.3 GB) copied, 29.7559 s, 144 MB/s

Taahhüdü yazan Mikulas Patocka için bir şapka ipucu.