Mój dom jest zaszyfrowany za pomocą ecryptfs. Czy ecryptfs prowadzi do fragmentacji?
Mam wrażenie, że czytanie plików, wyświetlanie folderów i logowanie stały się coraz wolniejsze (choć na początku nie było zauważalnie wolne). Dysk twardy powoduje hałas podczas wyszukiwania, nawet jeśli otworzę tylko plik tekstowy. W /home/.ecryptfs widzę wiele dużych archiwów (które prawdopodobnie zawierają zaszyfrowane pliki), więc zastanawiam się, czy defragmentacja online systemu plików Linux tutaj coś zyskuje.
Jakie opcje muszę zwiększyć wydajność? Czy powinienem zdecydować, czy może lepiej zrobić bez szyfrowania?
filesystem
performance
ecryptfs
defrag
Freddi
źródło
źródło
Odpowiedzi:
Phoronix przeprowadził zestaw testów i kilka artykułów na temat wydajności eCryptfs podczas szyfrowania katalogów domowych:
Uważam, że szyfrowanie (zgodnie z oczekiwaniami) zgodnie z testami porównawczymi wpływa w pewnym stopniu na wydajność odczytu i zapisu. W przypadku małych procesorów (procesory Atom) i szybkich dysków twardych (SSD) jest to być może bardziej zauważalne. To powiedziawszy, używając eCryptfs, płacisz tę karę wydajności tylko podczas odczytu / zapisu danych do katalogu domowego (a nie reszty systemu, tak jak w przypadku szyfrowania całego dysku). Co więcej, przy szybszych procesorach czas spędzony na szyfrowaniu / deszyfrowaniu często mieści się w IO czekając na dostęp do danych z dysku, co zwykle stanowi wąskie gardło.
Jeśli chodzi o konkretny problem, jeśli słyszysz dużo szumu związanego z „szukaniem dysku twardego”, wydaje mi się, że twój system zamienia dane z pamięci na dysk i tam iz powrotem. Jeśli wybrałeś użycie eCryptfs, Ubuntu automatycznie zaszyfruje twoją przestrzeń wymiany (która jest wymagana do zabezpieczenia zaszyfrowanych danych). Jednak szyfrowana zamiana jest również bardzo droga.
Osobiście przeciążam mój system dużą ilością pamięci RAM (8 GB w większości moich systemów) i całkowicie wyłączam swap.
źródło
Programuję z Pythonem w moim katalogu domowym i mam wirtualne środowisko Python dla pakietów projektów.
W przypadku moich programów czasy uruchamiania są znacznie wolniejsze na eCryptfs, ponieważ Python wydaje wiele wywołań systemowych stat () podczas lokalizowania plików modułów; ponieważ wiele z tych wywołań statystyki powoduje „nie znaleziono pliku”, a takie wyniki nigdy nie są buforowane, ale nadal płacimy karę za ecryptfs, wszystko jest konsekwentnie powolne.
Aktualizacja
W końcu usunąłem ecryptfs z mojego domowego katalogu, przenosząc punkt montowania ecryptfs do ~ / private, kopiując większość plików z ~ / private do mojego nieszyfrowanego katalogu głównego. Teraz wszystko znów jest szybkie. Może kara wydajności byłaby mniejsza dla niektórych innych procesorów, mam Asus 1215N z Atomem.
źródło
Nie wykonałem żadnych pomiarów twardego rdzenia, więc weźcie poniższe ziarno soli, ale zauważyłem wyjątkowo słabą wydajność ecryptfs w następujących scenariuszach w porównaniu do LV dm-crypt'd (zamontowanego jako / home / nazwa użytkownika):
du w folderze z dużą ilością plików. To zajmuje kilka minut, a zaledwie kilka sekund używa dm-crypt całej partycji - jest to zdecydowanie najgorszy przypadek
otwarcie folderu z dużą ilością elementów w Mutt zajmuje kilka sekund (około 20 w folderze z 10000 przedmiotów), podczas gdy jest prawie natychmiastowe z dm-crypt
Operacje git są wolniejsze (przez niektórych, niewiele) w porównaniu z dm-crypt
aplikacje takie jak firefox uruchamiają się znacznie dłużej, ale wciąż jesteśmy w zasięgu sekund
Właśnie przeniosłem się do dm-crypt (z pam_mount) i nie mogę być szczęśliwszy!
źródło
wywołania takie jak truncate () i ftruncate (), które zwiększają rozmiar pliku, są wolniejsze w ecryptfs, ponieważ musi wypełniać zaszyfrowane zera, w przeciwieństwie do normalnych systemów plików, które po prostu tworzą dziury w pliku.
źródło