Re: ecryptfs (war: Re: SSDs: Noch was zum TRIM-Support)
On Monday 11 July 2011, Martin Steigerwald wrote:
> Am Sonntag, 10. Juli 2011 schrieb Michael Schuerig:
> > On Sunday 10 July 2011, Martin Steigerwald wrote:
> > > Das erklärt es IMHO ganz nett.
> > >
> > > https://lwn.net/Articles/347511/
> >
> > Ich hab's ja nicht geglaubt, jetzt aber trotzdem mal discard für
> > mein ext4-Dateisystem ausgeschaltet. Für mein Home-Verzeichnis
> > habe ich über dem ext4 noch ein eCryptfs und das ist durch diese
> > Änderung in einem für mich wichtigen Punkt spürbar schneller
> > geworden:
> >
> > Ich hatte mich schon seit einer Weile darüber geärgert, das KMail
> > beim Springen zwischen ungelesenen Nachrichten (Leertaste oder
> > +-Taste) oft gezögert hat. Ohne discard ist das nicht mehr so.
>
> Nett mal von einer Praxiserfahrung zu lesen.
>
> ecryptfs: Läuft das schön?
Im Betrieb ist es völlig problemlos und nachdem nun die Verzögerungen in
KMail weg sind, fühlt es sich nochmal schneller an. Es gibt aber ein
paar Bugs! Einige Benutzer hatten Probleme damit, dass die
entschlüsselten Dateien angehängte 0-Bytes hatte. Es kann sein, dass der
Fehler inzwischen behoben ist. Ich bekomme in den letzten Versionen beim
Herunterfahren Kernel-OOPS-Traces im ecryptfs-Code.
> Ich verwende derzeit immer noch encfs. Mir
> ging damals auf den Keks das bei ecryptfs jede Datei immer
> mindestens 8 KiB oder was es war groß ist wegen der
> Crypto-Metadaten. encfs ist da sparsamer. Allerdings soll ecryptfs
> längst auch erweiterte Attribute dafür verwenden können und die
> lassen sich mit rsync --xattrs ja auch schön wegsichern.
Erweiterte Attribute habe ich nicht probiert. Macht die Minimalgröße
denn überhaupt etwas aus? D.h., ändert das etwas daran, wieviele Blöcke
für eine leere Datei mindestens allokiert werden?
Für mich bisher der einzige, allerdings gravierende Nachteil, von
eCryptfs ist, dass die Dateinamen und Pfade so endlos lang werden. Und
zwar so lang, dass man sie auf einem Strato-HiDrive nicht sichern kann.
Ich habe vor einer Weile angefangen, ein FUSE-FS zu schreiben, dass
lange Namen (und Metadaten, die auch verloren gehen) auf kürzere
abbildet. Damit komme ich aber nur sehr langsam voran und es wird noch
dauern, bis es irgendwie brauchbar sein wird.
Die Namen bei encfs sind von vornherein kürzer (SHA1 oder MD5, meine
ich). Allerdings ist encfs deutlich langsamer:
http://geekparadise.de/2011/04/linux-groser-geschwindigkeitsvergleich-
encfsecryptfstruecryptluks/
Ich benutze encfs (mit --reverse) ebenfalls fürs einen Teil meines
Online-Backups, da ist die FS-Performance ziemlich egal.
Michael
--
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/
Reply to: