ecryptfs und viele kleine Dateien - schlechte Leistung?

2135
Guy

Ich habe einen Ordner mit einigen hunderttausend kleinen Dateien, insgesamt etwa 14 GB Daten. Dies ist ein Ordner in meinem ecryptfs-verschlüsselten Ausgangsverzeichnis.

Das Erstellen eines "du -sh-Ordners" dauert mehr als 9 Minuten. Das Ausführen eines cp -rals an einem nicht verschlüsselten Ort dauert eine Stunde und 15 Minuten. Während dieser Zeit ist die CPU-Last meistens IO-gebunden (80% wa in top)

Ein "du -sh-verschlüsselter Ordner" dauert nur 15 Sekunden und ein cp -Ordner am selben Ort dauert nur 80 Sekunden. 'encryptedfolder' ist der Ordner in /home/.ecryptfs/myname/.Private, der die verschlüsselten Dateien enthält.

Ich bin verblüfft, wie dieser Performance-Hit passiert. Dieser Ordner wird über Nacht mit rsync gesichert, was nun mehr als zwei Stunden dauert. Bevor ich auf ecryptfs umgestiegen bin, habe ich truecrypt verwendet und das Backup in 12 Minuten ausgeführt.

Warum ist ecryptfs in diesem Szenario so miserabel? Die Operationen du -sh und cp -ral beinhalten keine Entschlüsselung des Dateiinhalts, sondern müssen nur den richtigen Dateinamen finden. Gibt es eine Möglichkeit, dies zu beschleunigen?

PS: Dies läuft auf Ubuntu 11.04

3

2 Antworten auf die Frage

2
tyhicks

Hier tragen einige Faktoren bei.

  1. Um eine Liste aller Dateinamen in einem Verzeichnis abrufen zu können, müssen die unteren Dateinamen dekodiert, analysiert und entschlüsselt werden.

  2. Die stat () - Aufrufe von du veranlassen eine Suche, die das Zuweisen eines eCryptfs-Inodes erfordert, das Lesen eines Teils der Metadaten der unteren Datei, das Überprüfen, ob es sich um eine eCryptfs-Datei handelt, und das anschließende Analysieren der unverschlüsselten Dateigröße, um das i_size-Feld des eCryptfs-Inodes festzulegen . Beachten Sie, dass das Lesen der Metadaten aus dem unteren Dateisystem das Lesen einer Seite in den Seitencache des unteren Dateisystems beinhaltet.

Aufgrund des Designs von eCryptfs ist der Aufwand für eine große Anzahl von Dateien mit Unannehmlichkeiten verbunden. Ich bin sicher, dass trotz des Designs einige Verbesserungen / Verbesserungen vorgenommen werden müssen, aber die Optimierung dieses Codeteils war bisher nicht mein Schwerpunkt.

Okay, das ist ein bisschen enttäuschend. Ich verschiebe den Ordner aber einfach aus meinem Home-Verzeichnis auf eine TrueCrypt-gesicherte Festplatte. Guy vor 12 Jahren 0
0
SecurityMatt

The simple answer is it isn't. The performance hit isn't from encryptfs being slow, it's from the need to allocate very large numbers of inodes and perform disk maintenance to put all of the metadata associated with the files on disk one-by-one.

If the folder is backuped nightly you might find it more useful to first "tar" the entire directory, compress the resulting file and then encrypt that (don't encrypt and then compress, because compression doesn't work on encrypted files). This way you'll have a backup that will be markedly smaller, and much faster to create and move around.

(1) Für du -sh ist es nicht erforderlich, etwas auf die Festplatte zu legen, dies ist nur Lesen. (2) Ihr Vorschlag mit tar ist nicht schneller, da er noch ecryptfs durchlaufen müsste (da sich dort der Ordner befindet). Außerdem würde ich es vorziehen, inkrementelle Backups zu erstellen und nicht jeden Tag eine neue große Datei zu erhalten. Guy vor 12 Jahren 0
Lesevorgänge müssen immer noch durch die Inode-Struktur durchlaufen werden (was eine Menge Umleitung bedeutet, die jeweils Plattenzugriff und ein Zurücksetzen der Verschlüsselungsvektoren erfordert). Ihr Punkt zu tar ist gültig, aber wenn Sie inkrementelle Sicherungen wünschen, sollten Sie wahrscheinlich SVN oder GIT verwenden, anstatt eine lokale Kopie zu erstellen SecurityMatt vor 12 Jahren 0
Danke für die Klarstellung. Ich akzeptiere jedoch nicht die Prämisse, dass svn / git ein Ersatz für Backups wäre. Je. In diesem Fall bin ich nicht einmal sicher, ob es überhaupt funktionieren würde oder die Dinge erheblich beschleunigen würde (es müsste immer noch alle Dateien durchgehen, um zu sehen, was sich geändert hat). Guy vor 12 Jahren 0
Zur Begründung meines Standpunkts: http://blog.codekills.net/2009/12/08/ using-git-for-backup-is-asking-for-pain/ http://ewout.name/2011/10/do -not-store-database-backups-in-git / Guy vor 12 Jahren 0
Sie haben zum ersten Mal Datenbanken erwähnt. Sie haben Recht, dass Sie eine Datenbank nicht in GIT sichern sollten, aber für normale Dateien, die sich selten ändern (z. B. Quellcode), ist dies dennoch eine gute Wahl. Für Datenbanksicherungen ist es wahrscheinlich besser, inkrementelle Unterschiede der Datenbank zu verwenden, das Ergebnis zu komprimieren (und möglicherweise zu verschlüsseln) und diese außerhalb des Standorts zu speichern. Denken Sie daran, dass ein Backup vor Ort überhaupt kein Backup ist, wenn Ihre Site vollständig verbrannt ist. SecurityMatt vor 12 Jahren 0
Ich habe keine Datenbank, dies ist nur ein Beispiellink. Die andere spricht nicht von Datenbanken, sondern listet andere Probleme auf. Und natürlich habe ich Off-Side-Backups :) Git (oder ähnliches) ist nur für Quellcode gedacht. In diesem speziellen Fall würde es der Performance auch nicht helfen - schließlich muss man zB "git commit" machen. Es würde immer noch git erfordern, um die gesamte Struktur zu scannen - kein Unterschied in dieser Hinsicht. Guy vor 12 Jahren 0
Git und SVN sind für den Umgang mit einer großen Anzahl kleiner Dateien gedacht, die sich nicht oft ändern. Sie kümmern sich nicht wirklich darum, ob diese Dateien Quellcode oder irgendetwas anderes enthalten. Auch GIT und SVN prüfen nicht die gesamte Struktur auf Änderungen - das ist der springende Punkt. SecurityMatt vor 12 Jahren 0
Wie würden git oder svn wissen, welche Datei hinzugefügt und welche geändert wurde, wenn nicht jede Datei geprüft wird, dh der Änderungszeitstempel. Dies hat genau den gleichen Aufwand wie der Zugriff auf die Metadaten der Dateigröße mit du (mit Ausnahme der Möglichkeit, einige Verzeichnisse zu ignorieren, aber in meinem Anwendungsfall müsste dies zumindest in die großen großen Ordner gehen). Und wie im ersten Link (http://blog.codekills.net/2009/12/08/ using-git-for-backup-is-asking-for-pain) beschrieben, sind weder git- noch svn-Backup-Metadaten außer Zeitstempel und Zugriff verfügbar Bits, wodurch es für generische Backups weniger geeignet ist. Guy vor 12 Jahren 0
Ich weiß nicht, wie es geht, aber wenn ich in meiner Firma Code aktualisiere, der buchstäblich Millionen von Quelldateien enthält, die Milliarden von Quellcodezeilen enthalten, erkennt er Änderungen sofort und liest sicherlich nicht alle 500 GB-Dateien in Sehen Sie, ob sich jeder geändert hat. Sehen Sie, ich möchte nicht unfreundlich sein, aber mir scheint, dass Sie bereits entschieden haben, dass ich falsch liege. Ich bin mir nicht sicher, ob es einen Grund gibt, diese Diskussion fortzusetzen. SecurityMatt vor 12 Jahren 0
Entschuldigung, Sie haben recht, ich bin nicht überzeugt, dass Sie recht haben, meistens, weil Sie nur sagen, dass es so ist, aber keine Argumente dafür haben. In Bezug auf Git-Dateizugriff, cmp. Fragen zu Stackoverflow, z. B. http://stackoverflow.com/questions/4075528/what-algorithm-git-uses-to-detect-the-changes-on-your-working-tree. Dies ist die gleiche wie bei du -sh Sie auf Ecryptfs?). Sicherungen, die git verwenden, sichern nicht alle Metadaten (z. B. Besitz) und machen sie daher für diesen Zweck ungeeignet. Auch das Löschen älterer Backups (tägliche Backups vor 5 Jahren?) Usw. ist nicht ohne weiteres möglich. Guy vor 12 Jahren 0

Verwandte Probleme