Як шифри впливають на продуктивність жорсткого диска?


11

У мене домашня дирекція зашифрована шифрами. Чи призводять шифри до фрагментації?

У мене таке відчуття, що читання файлів, відображення папок та входу в систему постійно ставали повільнішими та повільнішими (хоча спочатку це було не помітно повільно). Жорсткий диск видає багато шуму, навіть якщо я відкриваю лише текстовий файл. У /home/.ecryptfs я бачу багато великих архівів (які, можливо, містять зашифровані файли), тому мені цікаво, чи дефрагментація файлової системи Linux онлайн отримує щось.

Які варіанти я маю для підвищення продуктивності? Чи варто вирішувати, чи краще мені обійтися без шифрування?


можливо ваш зашифрований розділ заповнюється? Ви можете перевірити це командою df, pls? Будь ласка, відредагуйте початкову публікацію, щоб додати результат.
Майкл К

Відповіді:


10

Під час шифрування домашніх каталогів Phoronix провів набір тестів і пару статей про ефективність eCryptfs:

Моє відхилення від цих статей полягає в тому, що шифрування (як і очікувалося) відповідно до орієнтирів, впливає на ефективність читання і запису до певної міри. На малих процесорах (процесорах Atom) та на швидких жорстких дисках (SSD) це, мабуть, помітніше. Однак, використовуючи eCryptfs, ви сплачуєте пеню за ефективність лише під час читання / запису даних у свій домашній каталог (а не в іншій частині системи, як це було б із повним дисковим шифруванням). Крім того, при більш швидких процесорах кількість часу, витраченого на це шифрування / дешифрування, часто вписується в режим очікування вводу-виводу на доступ до даних з диска, що зазвичай є вузьким місцем.

Що стосується вашої конкретної проблеми, якщо ви чуєте багато шуму "пошук жорсткого диска", мені здається, що ваша система переміщує дані з пам'яті на диск і назад. Якщо ви вирішили використовувати eCryptfs, то Ubuntu автоматично зашифрує ваш обмінний простір (який необхідний для захисту ваших зашифрованих даних). Однак зашифрований своп теж дуже дорогий.

Особисто я перевантажую свої системи великою кількістю оперативної пам’яті (8 Гб на більшості моїх систем) і повністю відключаю своп.


6

Я програмую з python у своєму домашньому каталозі та маю віртуальне середовище Python для пакетів проектів.

У моїх програмах час запуску в eCryptfs значно повільніший, оскільки Python видає багато системних викликів stat () під час пошуку файлів модулів; оскільки багато з цих статистичних дзвінків призводять до "файлу не знайдено", і такі результати ніколи не кешуються, але ми все одно платимо штраф за шифри, речі постійно мляві.

Оновлення

Я в кінцевому підсумку видалив шифри з домашнього редактора, перемістивши точку кріплення ecryptfs до ~ / private, скопіювавши більшість файлів із ~ / private до моєї незашифрованої домашньої папки. Тепер справи знову швидко проходять. Можливо, продуктивність покарання буде меншою для якогось іншого процесора, у мене є Asus 1215N з Atom.


У мене є новий Pentium i7 QuadCore, і продуктивність для мене все ще гасить.
HDave

5

Я не робив жодних вимірювань жорсткого ядра, тому беру до уваги наступне із зерном солі, але я помітив надзвичайно низьку продуктивність із криптовалютами у наступних сценаріях порівняно з dm-crypt'd LV (встановлений як / home / username):

  • du у папці з великою кількістю файлів. Минувши кілька хвилин, використовуючи dm-крипту всього розділу, це лише кілька секунд - це, безумовно, найгірший випадок

  • відкриття папки з великою кількістю елементів у mutt займає кілька секунд (близько 20 у папці з 10000 елементами), хоча вона майже миттєва з dm-crypt

  • операції git проходять повільніше (на деякі, не багато) порівняно з dm-crypt

  • такі програми, як firefox, запускають помітно більше часу, але ми все ще в секундах

Я щойно перейшов до dm-crypt (з pam_mount) і не міг бути щасливішим!


1

виклики, такі як усікання () та ftruncate (), що збільшують розмір файлів, повільніше на шифрованих файлах, оскільки він повинен заповнюватися зашифрованими нулями, на відміну від звичайних файлових систем, які просто створюють отвори у файлі.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.