Bagaimana dampak ecryptfs terhadap kinerja harddisk?

Saya memiliki rumah saya yang dienkripsi langsung dengan ecryptfs. Apakah ecryptfs menyebabkan fragmentasi?

Saya merasa bahwa membaca file, menampilkan folder, dan login menjadi semakin lambat dan lambat (meskipun pada awalnya tidak terlalu lambat). Hard disk membuat banyak mencari kebisingan bahkan jika saya hanya membuka file teks. Di /home/.ecryptfs saya melihat banyak arsip besar (yang mungkin berisi file terenkripsi), jadi saya ingin tahu apakah defragmentasi sistem file Linux online mendapatkan apa pun di sini.

Opsi apa yang saya miliki untuk meningkatkan kinerja? Haruskah saya memutuskan apakah sebaiknya saya melakukannya tanpa enkripsi?

Phoronix telah menjalankan serangkaian pengujian dan beberapa artikel tentang kinerja eCryptfs ketika mengenkripsi direktori home:

• http://www.phoronix.com/scan.php?page=article&item=ubuntu_910_encryption&num=1
• http://www.phoronix.com/scan.php?page=article&item=ubuntu_jaunty_encrypt&num=1

Saya mengambil dari artikel-artikel adalah bahwa enkripsi (seperti yang diharapkan) sesuai dengan tolok ukur, tidak mempengaruhi kinerja membaca dan menulis pada tingkat tertentu. Pada CPU kecil (prosesor Atom), dan pada hard drive cepat (SSD), ini mungkin lebih terlihat. Yang mengatakan, dengan menggunakan eCryptfs, Anda hanya membayar penalti kinerja saat membaca / menulis data ke direktori home Anda (dan bukan seluruh sistem, seperti yang Anda lakukan dengan enkripsi disk penuh). Lebih jauh lagi, dengan prosesor yang lebih cepat, jumlah waktu yang dihabiskan untuk melakukan enkripsi / dekripsi sering cocok dalam IO menunggu mengakses data dari disk, yang biasanya merupakan hambatan.

Mengenai masalah khusus Anda, jika Anda mendengar banyak suara "hard disk seek", sepertinya sistem Anda menukar data dari memori ke disk, dan bolak-balik. Jika Anda memilih untuk menggunakan eCryptfs, maka Ubuntu akan secara otomatis mengenkripsi ruang swap Anda (yang diperlukan untuk melindungi data terenkripsi Anda). Namun, swap terenkripsi juga sangat mahal.

Secara pribadi, saya membebani sistem saya dengan banyak RAM (8GB pada sebagian besar sistem saya), dan menonaktifkan swap sepenuhnya.

Saya pemrograman dengan python di direktori home saya, dan saya memiliki lingkungan virtual Python untuk paket proyek.

Untuk program saya, waktu startup jauh lebih lambat pada eCryptfs karena Python mengeluarkan banyak stat () panggilan sistem ketika mencari file modul; karena banyak dari panggilan stat ini menghasilkan "file tidak ditemukan", dan hasil seperti itu tidak pernah di-cache, tetapi kami masih membayar penalti untuk ecryptfs, semuanya secara konsisten lamban.

Memperbarui

Saya akhirnya menghapus ecryptfs dari dir home saya dengan memindahkan mountpoint ecryptfs ke ~ / private, menyalin sebagian besar file dari ~ / private ke homefolder saya yang tidak dienkripsi. Segalanya sekarang cepat lagi. Mungkin penalti kinerja akan lebih sedikit untuk beberapa CPU lain, saya punya Asus 1215N dengan Atom.

Saya belum melakukan pengukuran hard core, jadi ikuti yang berikut dengan sebutir garam, tetapi saya perhatikan kinerja yang sangat buruk dengan ecryptfs dalam skenario berikut dibandingkan dengan LV crypt'd dm (dipasang sebagai / home / nama pengguna):

• du pada folder dengan banyak file. Dibutuhkan beberapa menit sementara hanya beberapa detik menggunakan dm-crypt seluruh partisi - ini adalah kasus terburuk

• membuka folder dengan banyak item dalam mutt memakan waktu beberapa detik (sekitar 20 pada folder dengan 10.000 item) sementara hampir seketika dengan dm-crypt

• operasi git lebih lambat (oleh beberapa, tidak banyak) dibandingkan dengan dm-crypt

• aplikasi seperti firefox membutuhkan waktu lebih lama untuk memulai tetapi kami masih dalam kisaran detik

Saya baru saja pindah ke dm-crypt (dengan pam_mount) dan tidak bisa lebih bahagia!

panggilan seperti truncate () dan ftruncate () yang meningkatkan ukuran file lebih lambat pada ecryptfs karena harus diisi dengan nol yang dienkripsi, tidak seperti sistem file normal yang hanya membuat lubang di file.