Погана ефективність запису на шифрах

Я трохи провів бенчмаркінг із криптовалютами та dm-crypt, і отримав кілька цікавих результатів. Все наступне було виконано за допомогою файлової системи Btrfs, використовуючи ddдля копіювання файлу ~ 700 Мб в / з рамного диска з conv=fdatasyncможливістю примусової синхронізації даних. Кеш диска очищався перед кожним тестом.

No encryption:
 read - 165MB/s
 write - 120MB/s
ecryptfs:
 read - 125MB/s
 write - 15MB/s
dm-crypt:
 read - 150MB/s
 write - 115MB/s
dm-crypt + ecryptfs:
 read - 120MB/s
 write - 15MB/s

Тепер я розумію, що шифрування відбувається повільніше, ніж у сирої файлової системи, проте я не сподівався на масштабне падіння продуктивності запису за допомогою encryptfs. Чи те, що я змушую синхронізувати дані, робить цей тест нереальним? Або є якісь варіанти, з якими я можу перейти до encryptfs, щоб швидше писати роботу?

Я використовував шифрування імен файлів у ecryptfs, але крім цього, усе було встановлено за замовчуванням.

— Ксенопатичний
джерело

Бенчмаркінг може бути важким, і іноді тест досягає деяких несподіваних меж, особливо при вимушенні синхронних записів. Я не знайомий з внутрішньою роботою шифрів, але ви повинні переконатися, що виключаєте будь-які проблеми з посиленням запису. Який розмір блоку використовує ecryptfs і що ви вказали для dd? Якщо encryptfs зашифровує 16 кбіт одночасно, а ви пишете блоки, менші, кожна синхронізація змусить читати дістати блок, змінювати дані, шифрувати і, нарешті, записувати. Це може пояснити такі показники ефективності.

— ketil

Сторінка man ddabout about read fdatasync:, physically write output file data before finishingтому вона записує дані лише фізично "один раз" (читайте це як "не примушуючи флеш кожного X блоку чи байта, а єдиний флеш в кінці"). Якщо ви ddробите тести, це найкращий спосіб отримати найточніші результати. Навпаки, невикористання цього конкретного прапора призведе до того, що результати будуть нереальними: якщо пропустити, то, можливо, буде втрачено час для самого шифрування, оскільки ddце просто копіювання даних.

Тим не менш, я також думав, що відбувається щось, що стосується ваших результатів, але я знайшов цю статтю, яка показує майже те саме: шифри - це болісно повільно. І ваш тест ( копіюється один файл ) - найкращий сценарій для шифрів!

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

Однак, у шифрів є свої переваги: ви можете відправити зашифрований файл відразу, не втрачаючи шифрування. Ваші резервні копії (якщо припускати, що ви створюєте резервну копію зашифрованих даних) були б швидшими, оскільки ви копіюватимете лише файли, такі великі, як ваші дані (та ще швидше, якщо вони будуть додаткові, оскільки ви копіюєте лише змінені файли).

З іншого боку, dm-crypt може бути набагато швидшим, але вам потрібно буде надіслати весь контейнер (цілу файлову систему), щоб зберегти шифрування таким, яким воно є. А резервні копії також складалися б із всього контейнера, у більшості випадків вони не могли робити додаткові резервні копії.

Я використовував (і досі використовую) обидва способи (не ті самі інструменти, хоча) для зберігання зашифрованих даних: на основі файлів (ecryptfs) легше синхронізуватися через онлайн-сервіси хостингу, такі як dropbox між ПК, але це досить повільно, коли внесення змін і викликало у мене деякі проблеми з підкладеною файловою системою (передбачається, що вона може записувати файли, а проблеми, пов'язані з обмеженнями у файловій системі, як правило, порушують все); Я вважаю за краще блокове шифрування пристрою: я розглядаю їх як прості розділи, тому обмеження та проблеми не порушуються так погано. Єдиний недолік - копіювання контейнера, що може зайняти більше часу.

— NuTTyX
джерело