LVM + LUKS + SSD + Gentoo - làm cho tất cả hoạt động cùng nhau


7

Tôi đang tìm thấy rất nhiều thông tin mâu thuẫn ngoài kia, và cho đến nay vẫn chưa tìm thấy ai cố gắng tập hợp tất cả các thành phần mà tôi đang cố gắng thực hiện, vì vậy tôi hy vọng ai đó hiểu được SSD, LVM được mã hóa và như vậy có thể dừng lại và giúp đỡ

Về cơ bản, hệ thống của tôi là một máy tính xách tay với:

  • / dev / sda: SSD 32 GB
  • / dev / sdb: SSD 256 GB
  • / dev / sdc: 1000 GB HD

Nói chung các bản cài đặt Linux của tôi bao gồm ba phân vùng:

  • ~ 50 mb / lần khởi động
  • lớn / nhà
  • ~ 30 gb "mọi thứ khác"

Vì vậy, hiệu quả tôi muốn

  • /dev/sda1 -> /boot
  • /dev/sda2 -> /
  • /dev/sdb1 -> /home
  • /dev/sdc1 -> /swap
  • /dev/sdc2 -> /mnt/storage

Điều thú vị là tôi muốn mã hóa tất cả những thứ này (ngoại trừ /boot/mnt/storagecó thể không được mã hóa). Tôi đã đọc rằng khi mã hóa SSD có thể có vấn đề với những thứ như TRIM và lý tưởng nhất là tôi muốn sử dụng EXT4 với một số tùy chọn cụ thể và tôi phải rất cẩn thận với căn chỉnh phân vùng và một số chỉ cho rằng đã được mã hóa LVM thực sự không chơi tốt với SSD và tôi chỉ nên sử dụng EncFS hoặc eCryptfs (mặc dù mọi người dường như không rõ ràng và / hoặc phân cực về việc liệu chúng có nên được sử dụng để mã hóa các phân vùng "mount-at-boot" như / và / home) hay không.

Có bất kỳ thông tin kinh điển về điều này?


1
Trước hết hãy chắc chắn rằng bạn thậm chí cần phải lo lắng về TRIM. Nhiều ổ SSD ngày nay hoàn toàn không sử dụng nó, vì vậy hãy xác minh trước khi bạn lãng phí thời gian / công sức để cố gắng làm cho nó hoạt động. Thứ hai, tôi sẽ không sử dụng EncFS hoặc eCryptfs, đặc biệt là cho một phân vùng gốc. Cả hai đều chậm và không mang lại lợi ích gì cho những thứ như LUKS (khi mã hóa toàn bộ khối lượng). Ngoài ra, lần cuối cùng tôi thử sử dụng eCryptfs, nó đã làm hỏng mọi tệp duy nhất (và đó là phiên bản được cho là 'ổn định').
Patrick

2
TRIM đi qua tất cả các lớp của trình ánh xạ thiết bị trong các hạt nhân gần đây, vì vậy tất cả những gì bạn cần làm là đảm bảo rằng bạn đã discardchỉ định làm tùy chọn gắn kết cho hệ thống tệp.
Michael Hampton

1
Hừm ... từ kết quả tìm kiếm, có vẻ như TRIM sẽ là một điều tốt với tôi (Samsung SSD 830 256GB), vì vậy tôi chắc chắn sẽ làm discardđiều đó. Có điều gì khác đặc biệt tôi cần phải làm, căn chỉnh wrt và như vậy không? Các báo cáo về điều đó dường như cũng mâu thuẫn
Mala

@Mala là câu trả lời của tôi đủ tốt để được chọn là Câu trả lời?
lkraav

Câu trả lời:


4

Bây giờ tôi đang chạy btrfs trên dm-crypt. Vì btrfs là một hệ thống tập tin đa năng có khả năng và năng động (tăng trưởng, thu nhỏ, v.v.), tôi không thực sự cần lớp LVM cho mục đích của mình.

Ngoài ra, sử dụng một dm-crypt đủ gần đây có --allow-discardskhả năng, kernel 3.1+ và hệ thống tập tin cũng cho phép loại bỏ (btrfs, ext *, ...).

Một số thứ để đọc qua làm tất cả điều này:

Tôi sẽ cập nhật với nhiều liên kết hơn theo thời gian khi tôi tìm thấy chúng từ vực thẳm dấu trang của mình:>

Tôi đã không điểm chuẩn thiết lập của tôi đặc biệt nhiều. Đối với tôi, nó hoạt động nhiều hơn mức hiệu quả, tức là vẫn đi trước ổ cứng. Bây giờ tôi không biết chính xác SSD của tôi đang ở trạng thái nào và liệu hệ thống loại bỏ nhiều lớp có thực sự hoạt động 100% hay không. Điều quan trọng hơn là tôi có đủ hiệu suất với đủ mô hình bảo mật để chống lại các vấn đề có xác suất cao hơn, chẳng hạn như quên thiết bị, thiết bị bị đánh cắp bởi những người ngẫu nhiên, v.v.

Vì vậy, việc tìm hiểu chính xác tuổi thọ SSD của tôi có thể rút ngắn bao nhiêu hoặc hiệu suất bị chậm lại do hệ thống loại bỏ không hoạt động chính xác 100% cho TRIM hoặc bao nhiêu dm-crypt làm suy yếu bảo mật vốn có của nó - Tôi không thể thu thập thông tin bảo đảm cho những câu hỏi này một ưu tiên cao. Một trong những lý do tôi viết câu trả lời này có lẽ là tôi đã sai quá nhiều và đưa nó ra đây hiện là cách tối ưu để tôi cố gắng tìm hiểu.


cảm ơn vì những lời khuyên! Tôi hy vọng ai đó đi cùng và sắp xếp cả hai chúng tôi ra :)
Mala
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.