Làm thế nào để ecryptfs tác động đến hiệu suất ổ cứng?


11

Tôi có nhà của tôi được mã hóa bằng ecryptfs. Liệu ecryptfs dẫn đến sự phân mảnh?

Tôi có cảm giác rằng việc đọc các tập tin, hiển thị các thư mục và đăng nhập liên tục trở nên chậm hơn và chậm hơn (mặc dù lúc đầu nó không chậm một cách đáng chú ý). Đĩa cứng tạo ra nhiều tiếng ồn tìm kiếm ngay cả khi tôi chỉ mở một tệp văn bản. Trong /home/.ecryptfs tôi thấy nhiều tài liệu lưu trữ lớn (có thể chứa các tệp được mã hóa), vì vậy tôi tự hỏi liệu hệ thống phân mảnh trực tuyến của Linux có thu được gì ở đây không.

Tôi có những lựa chọn nào để tăng hiệu suất? Tôi có nên quyết định liệu tôi có thể làm tốt hơn mà không cần mã hóa không?


Có lẽ phân vùng được mã hóa của bạn đã đầy? bạn có thể kiểm tra điều này với lệnh df không? Vui lòng chỉnh sửa bài viết ban đầu của bạn để thêm đầu ra.
Michael K

Câu trả lời:


10

Phoronix đã chạy một bộ thử nghiệm và một vài bài viết về hiệu suất của eCryptfs khi mã hóa các thư mục nhà:

Tôi tránh xa những bài báo đó là mã hóa (như mong đợi) theo điểm chuẩn, không ảnh hưởng đến hiệu suất đọc và ghi ở mức độ. Trên các CPU nhỏ (bộ xử lý nguyên tử) và trên các ổ cứng nhanh (SSD), điều này có lẽ đáng chú ý hơn. Điều đó nói rằng, bằng cách sử dụng eCryptfs, bạn chỉ phải trả tiền phạt hiệu suất khi đọc / ghi dữ liệu vào thư mục chính của bạn (chứ không phải phần còn lại của hệ thống, như bạn đã làm với mã hóa toàn bộ đĩa). Hơn nữa, với các bộ xử lý nhanh hơn, lượng thời gian dành cho việc mã hóa / giải mã đó thường phù hợp với IO chờ truy cập dữ liệu từ đĩa, thường là nút cổ chai.

Đối với vấn đề cụ thể của bạn, nếu bạn nghe thấy nhiều tiếng ồn "tìm kiếm đĩa cứng", thì có vẻ như hệ thống của bạn đang hoán đổi dữ liệu từ bộ nhớ sang đĩa và qua lại. Nếu bạn đã chọn sử dụng eCryptfs, thì Ubuntu sẽ tự động mã hóa không gian hoán đổi của bạn (cần thiết để bảo vệ dữ liệu được mã hóa của bạn). Tuy nhiên, trao đổi mã hóa là rất tốn kém, quá.

Cá nhân, tôi làm quá tải hệ thống của mình với rất nhiều RAM (8GB trên hầu hết các hệ thống của tôi) và vô hiệu hóa hoàn toàn trao đổi.


6

Tôi đang lập trình với python trong thư mục nhà của mình và tôi có một môi trường ảo Python cho các gói dự án.

Đối với các chương trình của tôi, thời gian khởi động chậm hơn đáng kể trên eCryptfs vì Python phát hành nhiều lệnh gọi hệ thống stat () khi định vị tệp mô-đun; bởi vì nhiều cuộc gọi trong số các kết quả này dẫn đến "không tìm thấy tệp" và các kết quả như vậy không bao giờ được lưu trong bộ nhớ cache, nhưng chúng tôi vẫn phải trả tiền phạt cho các mã hóa điện tử, mọi thứ luôn chậm chạp.

Cập nhật

Cuối cùng tôi đã xóa ecryptfs khỏi thư mục nhà của mình bằng cách di chuyển điểm gắn kết của ecryptfs sang ~ / private, sao chép hầu hết các tệp ra khỏi ~ / private vào trang chủ không được mã hóa của tôi. Mọi thứ bây giờ lại nhanh chóng. Có thể hình phạt hiệu năng sẽ ít hơn đối với một số CPU khác, tôi có Asus 1215N với Atom.


Tôi có một Pentium i7 QuadCore mới và hiệu suất vẫn còn hấp dẫn đối với tôi.
HDave

5

Tôi chưa thực hiện bất kỳ phép đo lõi cứng nào vì vậy hãy thực hiện các thao tác sau với một hạt muối nhưng tôi nhận thấy hiệu suất cực kỳ kém với các mã hóa trong các trường hợp sau so với LV của dm-crypt'd (được gắn dưới dạng / home / tên người dùng):

  • du trên một thư mục có rất nhiều tập tin. Phải mất vài phút trong khi chỉ một vài giây sử dụng dm-crypt của toàn bộ phân vùng - đây là trường hợp xấu nhất

  • mở một thư mục có nhiều mục trong mutt mất vài giây (khoảng 20 trên một thư mục có 10000 mục) trong khi nó gần như tức thời với dm-crypt

  • hoạt động của git chậm hơn (bởi một số, không nhiều) so với dm-crypt

  • các ứng dụng như firefox mất nhiều thời gian hơn để bắt đầu nhưng chúng tôi vẫn ở trong phạm vi giây

Tôi mới chuyển đến dm-crypt (với pam_mount) và không thể hạnh phúc hơn!


1

các cuộc gọi như truncate () và ftruncate () làm tăng kích thước tệp chậm hơn trên ecryptfs vì nó phải điền vào các số 0 được mã hóa, không giống như các hệ thống tệp thông thường chỉ tạo lỗ trong tệp.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.