Niska wydajność zapisu w ecryptfs

Zrobiłem trochę testów porównawczych z ecryptfs i dm-crypt i uzyskałem kilka interesujących wyników. Wszystkie poniższe czynności wykonano w systemie plików Btrfs, używając dddo skopiowania pliku ~ 700 MB do / z ramdysku z conv=fdatasyncopcją wymuszenia synchronizacji danych. Pamięci podręczne dysków zostały wyczyszczone przed każdym testem.

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

Teraz rozumiem, że szyfrowanie jest wolniejsze niż surowy system plików, jednak nie spodziewałem się znacznego spadku wydajności zapisu w ecryptfach. Czy fakt, że wymuszam synchronizację danych, sprawia, że ten test jest nierealny? Czy są jakieś opcje, które mogę przekazać do ecryptfs, aby zapisy działały szybciej?

Używałem szyfrowania plików na ecryptfs, ale poza tym wszystko było ustawione na domyślne.

— Ksenopatyczny
źródło

Benchmarking może być trudny, a czasami test napotyka pewne nieoczekiwane ograniczenia, szczególnie w przypadku wymuszania zapisu synchronicznego. Nie jestem zaznajomiony z wewnętrznym działaniem ecryptfs, ale powinieneś upewnić się, że wykluczasz jakiekolwiek problemy ze wzmocnieniem zapisu. Jakiego rozmiaru bloku używa ecryptfs i co określiłeś dla dd? Jeśli ecryptfs szyfruje jednocześnie 16kb i piszesz bloki, które są mniejsze, każda synchronizacja wymusi odczyt, aby pobrać blok, następnie zmienić dane, następnie zaszyfrować, a na koniec zapisać. To może wyjaśnić takie wyniki.

— ketil

Strona podręcznika ddabout fdatasyncczyta:, physically write output file data before finishingwięc zapisuje dane fizycznie tylko „raz” (czytaj to jako „nie wymuszając koloru co X bloków lub bajtów, ale pojedynczy kolor na końcu”). Jeśli używasz dddo przeprowadzania testów, jest to najlepszy sposób na uzyskanie najdokładniejszych wyników. Przeciwnie, brak użycia tej konkretnej flagi sprawiłby, że wyniki byłyby nierealistyczne: pominięcie go prawdopodobnie straciłoby czas na samo szyfrowanie, ponieważ ddjest to po prostu kopiowanie danych.

Niemniej jednak myślałem, że coś się dzieje, jeśli chodzi o twoje wyniki, ale znalazłem ten artykuł, który pokazuje prawie to samo: ecryptfs jest boleśnie powolny. Twój test ( kopiowany pojedynczy plik ) jest najlepszym scenariuszem dla ecryptfs!

Ponieważ ecryptfs zapisuje zaszyfrowany plik (z niestandardowym nagłówkiem z metadanymi w środku) dla każdej wersji tekstu jawnego, posiadanie wielu małych plików oznacza jeszcze większy spadek wydajności.

Jednak ecryptfs ma swoje zalety: możesz wysłać zaszyfrowany plik od razu bez utraty szyfrowania. Kopie zapasowe (zakładając, że tworzysz kopie zapasowe zaszyfrowanych danych) byłyby szybsze, ponieważ kopiowałbyś tylko pliki tak duże jak twoje dane (a nawet szybciej, jeśli są one przyrostowe, ponieważ kopiowałbyś tylko zmodyfikowane pliki).

Z drugiej strony, dm-crypt może być znacznie szybszy, ale trzeba by wysłać cały kontener (cały system plików), aby zachować szyfrowanie w niezmienionej postaci. A kopie zapasowe składałyby się również z całego kontenera, w większości przypadków nie mogąc tworzyć przyrostowych kopii zapasowych.

Użyłem (i nadal używam) obu metod (jednak nie tych samych narzędzi) do przechowywania zaszyfrowanych danych: w oparciu o pliki (ecryptfs) łatwiej jest utrzymać synchronizację za pośrednictwem usług hostingu online, takich jak Dropbox między komputerami, ale jest dość powolny, gdy wprowadzanie zmian i spowodowało mi pewne problemy z podkładającym się systemem plików (zakłada, że może on zapisywać pliki, a problemy związane z ograniczeniami w systemie plików zwykle psują całość); Wolę szyfrowanie urządzeń blokowych: traktuję je jako proste partycje, więc limity i problemy nie psują się tak źle. Jedyną wadą jest kopiowanie kontenera, co może potrwać znacznie dłużej.

— NuTTyX
źródło