ecryptfs и много много маленьких файлов - плохая производительность?

2099
Guy

У меня есть папка с несколькими сотнями тысяч небольших файлов, общим объемом около 14 ГБ данных. Это папка в моей зашифрованной домашней директории ecryptfs.

Создание папки du -sh занимает более 9 минут. Выполнение cp -ral в незашифрованном месте занимает час и 15 минут. Загрузка ЦП в это время в основном связана с вводом-выводом (80% ва сверху)

Создание зашифрованной папки du -sh занимает всего 15 секунд, а cp -ral в том же месте занимает всего 80 секунд. «encryptedfolder» - это папка в /home/.ecryptfs/myname/.Private, которая содержит зашифрованные файлы.

Я сбит с толку, как происходит этот хит производительности. Резервное копирование этой папки осуществляется через rsync, что теперь занимает более двух часов. Прежде чем я переключился на ecryptfs, я использовал truecrypt, и резервное копирование выполнялось за 12 минут.

Почему ecryptfs так ужасно медленен в этом сценарии? Операции du -sh и cp -ral не требуют расшифровки содержимого файла, а просто находят правильное имя файла. Есть ли способ ускорить это?

PS: это работает на Ubuntu 11.04

3

2 ответа на вопрос

2
tyhicks

Здесь есть пара способствующих факторов.

  1. Получение списка всех имен файлов в каталоге требует декодирования, анализа и расшифровки нижних имен файлов.

  2. Вызовы stat () из du вызывают поиск, который требует выделения inode eCryptfs, чтения части метаданных нижнего файла, проверки того, что это файл eCryptfs, а затем анализа незашифрованного размера файла для установки поля i_size inode в eCryptfs., Имейте в виду, что чтение метаданных из нижней файловой системы включает чтение страницы в кэш страницы нижней файловой системы.

Из-за дизайна eCryptfs, он имеет некоторые печальные издержки при работе с большим количеством файлов. Я уверен, что есть некоторые улучшения / улучшения, которые должны быть сделаны, несмотря на дизайн, но оптимизация этой части кода ранее не была моей задачей.

Хорошо, это немного разочаровывает. Но я просто перенесу папку из моего домашнего каталога на защищенный диск TrueCrypt. Guy 12 лет назад 0
0
SecurityMatt

Простой ответ - нет. Снижение производительности происходит не из-за медленной функции encryptfs, а из-за необходимости выделять очень большое количество inode и выполнять обслуживание диска, чтобы поместить все метаданные, связанные с файлами, на диск один за другим.

Если папка резервируется ночью, может оказаться более полезным сначала «заархивировать» весь каталог, сжать полученный файл, а затем зашифровать его (не шифруйте, а затем сжимайте, потому что сжатие не работает с зашифрованными файлами). Таким образом, у вас будет резервная копия, которая будет значительно меньше и намного быстрее будет создаваться и перемещаться.

(1) Для du -sh нет необходимости помещать что-либо на диск, это просто чтение. (2) Ваше предложение с tar не быстрее, потому что оно все равно должно было бы пройти через ecryptfs (поскольку там хранится папка), также я бы предпочел делать инкрементные резервные копии и не получать новый огромный файл каждый день. Guy 12 лет назад 0
Чтения все еще должны проходить через структуру inode (что является большим количеством косвенных указаний, каждое из которых требует доступа к диску и сброса векторов шифрования). Ваш пункт о tar действителен, но если вы хотите создавать инкрементные резервные копии, вам, вероятно, следует использовать SVN или GIT вместо локальной копии SecurityMatt 12 лет назад 0
Спасибо за разъяснения. Однако я не принимаю предпосылку, что svn / git будет заменой резервных копий. Когда-либо. В этом случае я даже не уверен, что он будет работать вообще или сделает вещи значительно быстрее (ему все равно нужно будет просмотреть все файлы, чтобы увидеть, что изменилось). Guy 12 лет назад 0
Чтобы обосновать мою точку зрения: http://blog.codekills.net/2009/12/08/using-git-for-backup-is-asking-for-pain / http://ewout.name/2011/10/do -на-магазин-база-подпорка-в-мерзавца / Guy 12 лет назад 0
Вы впервые упомянули базы данных. Вы правы, что вам не следует создавать резервные копии базы данных в GIT, но для обычных файлов, которые редко изменяются (например, исходный код), это все еще хороший выбор. Для резервных копий базы данных вам, вероятно, лучше взять инкрементные различия в базе данных, сжать (и, возможно, зашифровать) результат и сохранить их за пределами сайта. Помните, что резервное копирование на месте вообще не является резервным копированием, когда ваш сайт сгорает на землю. SecurityMatt 12 лет назад 0
У меня нет базы данных, это просто пример ссылки. Другой не говорит о базах данных, но перечисляет другие проблемы. И, конечно, у меня есть резервные копии вне игры :) Git (или аналогичный) просто не предназначен ни для чего, кроме исходного кода. В этом конкретном случае это также не поможет производительности - в конце концов нужно будет сделать, например, «git commit». все равно потребуется git для сканирования всей структуры - без разницы в этом отношении. Guy 12 лет назад 0
Git и SVN предназначены для работы с большим количеством маленьких файлов, которые меняются не очень часто. Их не волнует, содержат ли эти файлы исходный код или что-то еще. Также GIT и SVN не сканируют всю структуру на предмет изменений - в этом их суть. SecurityMatt 12 лет назад 0
Как git или svn узнают, какой файл был добавлен, а какой был изменен, если не проверять каждый файл, то есть метку времени изменения. Это имеет те же издержки, что и доступ к метаданным размера файла с помощью du (за исключением, возможно, возможности игнорировать некоторые каталоги, но в моем случае использования он должен был бы войти по крайней мере в основные большие папки). И, как указано в первой ссылке (http://blog.codekills.net/2009/12/08/using-git-for-backup-is-asking-for-pain), ни метаданные git, ни svn не создают резервные копии, кроме меток времени и доступа биты, что делает его неидеальным для общих резервных копий. Guy 12 лет назад 0
Я не знаю, как это происходит, но когда я обновляю код в моей компании, в которой буквально миллионы исходных файлов, содержащих миллиарды строк исходного кода, он обнаруживает изменения мгновенно и, конечно, не читает все 500 ГБ файлов в посмотрим, изменился ли каждый из них. Послушай, я не хочу быть недобрым, но мне кажется, что ты уже решил, что я неправ, поэтому я не уверен, что на самом деле есть какая-то причина для продолжения этого обсуждения. SecurityMatt 12 лет назад 0
Извините, вы правы, я не уверен, что вы правы, в основном потому, что вы только говорите, что это так, но не имеете никаких аргументов, почему. Относительно доступа к файлу git, cmp. вопросы по stackoverflow, например, http://stackoverflow.com/questions/4075528/what-algorithm-git-uses-to-detect-the-changes-on-your-working-tree, который такой же, как du -sh ( ты на ecryptfs?). А резервные копии, использующие git, не создают резервные копии всех метаданных (например, владельца) и, таким образом, делают их непригодными для этой цели. Кроме того, удалить старые резервные копии (ежедневные резервные копии от 5 лет назад?) И т. Д. Нелегко. Guy 12 лет назад 0

Похожие вопросы