Bố cục phân vùng cho SSD + 3 ổ cứng


2

Hôm qua tôi có máy trạm mới có tính năng:

  • 120 GB - OCZ Vertex3 MAX IOPS
  • 300 GB - Velociraptor kỹ thuật số phương Tây (10k RPM, khoảng 4ms avg. Tìm kiếm)
  • 2x2TB Samsung Ecogreen F4

Hệ thống sẽ chạy Ubuntu với mục đích chính là thực hiện nhiều hoạt động phát triển Java. Thỉnh thoảng tôi phải phát triển Java trong Windows VM; Đối với điều này, tôi cần VM nhanh. Tôi đã đọc rất nhiều về sự hao mòn của SSD và có lẽ đó là một ý tưởng tồi khi đặt không gian làm việc của Eclipse vào SSD, bởi vì tất cả các công việc viết nhỏ đều làm. Có lẽ không gian làm việc (và do đó / nhà) có thể tìm thấy một nơi tốt hơn trên Velociraptor rất nhanh.

Làm thế nào tôi nên phân vùng toàn bộ để tận dụng tối đa nó? Tôi cởi mở với bất kỳ đề nghị. LVM cũng có thể là một lựa chọn. Có lẽ việc đặt phân vùng thứ ba trên SSD cho một hình ảnh VirtualBox sẽ là một ý tưởng hay.

Hiện tại tôi đang suy nghĩ:

  • SSD: 2GB / lần khởi động, dung lượng còn lại cho /
  • Velociraptor: LVM trải dài trên toàn bộ ổ đĩa.
    • 150GB / nhà
    • Không gian còn lại cho / virtualMachines hoặc đại loại như thế
  • Ổ đĩa Samsung (LVM trên cả hai hoặc một Nhóm âm lượng cho mỗi? - Latter sẽ tốt hơn về mặt bảo mật dữ liệu, bởi vì nếu một ổ đĩa trong một nhóm âm lượng lớn bị hỏng thì mọi thứ sẽ bị mất)
    • Phân vùng cho dữ liệu, lưu trữ, vv

Câu trả lời:


0

Có một lựa chọn khác nếu độ tin cậy, mức độ hao mòn và sự khác biệt giữa tốc độ ghi và tốc độ đọc là điều đáng quan tâm:

Tôi có ổ đĩa RAM chạy bằng pin Acard 9010 mà tôi chạy Linux từ đó. Nó sẽ tốn nhiều chi phí hơn so với chi phí của SSD trung bình, nhưng bạn có được một số lợi thế:

  • Tốc độ đọc nhanh VÀ tốc độ ghi nhanh. SSD có tốc độ đọc thực sự nhanh và tốc độ ghi nhanh hơn một chút.
  • Không cần mặc san lấp mặt bằng.
  • Không có lo ngại về việc đĩa đầy đủ ghi chậm hơn đĩa trống như tồn tại trên SSD
  • Các đốm năng lượng được bao phủ bởi pin bên trong trong khoảng một ngày và bạn cũng có thể sử dụng mụn cóc bên ngoài để cung cấp năng lượng cho ổ đĩa ram (ngoài pin dự phòng bên trong).
  • Lưu trữ lâu hơn thời lượng pin của dữ liệu của bạn được giải quyết bằng thẻ SD được tích hợp trong thiết bị: khi tắt nguồn và điện áp pin ở mức thấp nhất định, RAM-Drive sẽ sao lưu nội dung của bộ nhớ vào đèn flash nhỏ gọn 64 GB Thẻ được tích hợp ở phía trước ổ đĩa ram, sau đó bật nguồn, nó sao chép dữ liệu thẻ SD trở lại Ram trong ổ đĩa ram.

Để trả lời trực tiếp một phần câu hỏi, cách sắp xếp phân vùng trên ổ SSD (hoặc ổ RAM):

Tôi đặt mọi thứ trừ /homeổ đĩa ram. /homeđi trên một ổ cứng. Mất khoảng 5 GB cho Slackware64, vì vậy trong ổ RAM 32 GB, tôi có nhiều không gian để phát triển.

Bạn không phải thực hiện công việc của mình /home, mặc dù đó là "cách linux" thông thường, thay vào đó hãy nghĩ đến việc tạo một thư mục trong cây Linux như /javahoặc /projectssẽ có trên ổ đĩa ram của bạn, đặt quyền và quyền sở hữu để người dùng của bạn có thể để sử dụng thư mục đó và đưa các dự án của bạn vào ổ SSD / RAM để tăng tốc. Đặt hệ điều hành / công cụ / mã nguồn của bạn vào ổ đĩa RAM, làm việc ở đó, sau đó có một kịch bản tắt máy sao chép công việc hàng ngày của bạn vào ổ cứng.

Để đo lường vành đai và treo, tôi đã viết một vài tập lệnh đơn giản sao lưu các tệp quan trọng do người dùng tạo trên ổ đĩa RAM (hoặc SSD) trong trường hợp gặp sự cố. Các tệp như của bạn /etc/fstab/etc/X11/xorg.confcó thể gây rắc rối để nhanh chóng xử lý chính xác (đặc biệt nếu bạn có một loạt máy nghe nhạc mp3 trong fstab hoặc cài đặt màn hình phức tạp trong xorg.conf, v.v., trong các tệp đó), nếu bạn gặp vấn đề với SSD / RAM bị xáo trộn tại bất kỳ điểm nào.

Tôi cũng có một cặp tập lệnh sao lưu / khôi phục mọi tập tin duy nhất trên ổ đĩa ram vào một thư mục trở lại trên một ổ đĩa cứng, chỉ trong trường hợp. Tôi đề cập đến các tập lệnh này bởi vì một câu trả lời khác đã đề cập đến các vấn đề về độ tin cậy với SSD (hoặc ổ RAM). Các kịch bản cung cấp cho tôi một biện pháp dự phòng bổ sung và phục hồi dễ dàng, nếu một số thứ bị sai ở một số điểm. Thiết lập một công việc chron để sao lưu nhiều lần trong ngày nếu bạn muốn, dù sao cũng không phải là một ý tưởng tồi.

Vậy tôi làm cái gì:

  • / trên ổ SSD
  • /work( /javahoặc /projectshoặc khác) cho khu vực làm việc của bạn, trên SSD
  • /home trên ổ cứng
  • /usr/scripts (được tạo cho các tập lệnh do người dùng tạo)
  • tập lệnh để sao lưu tập tin cấu hình người dùng từ SSD vào ổ cứng
  • kịch bản để sao chép hoàn toàn ổ đĩa RAM vào ổ cứng.

Ổ đĩa RAM có thời gian truy cập 0,01 ms theo trang web của họ. Nó nhanh hơn nhiều so với HD nhưng không gấp đôi (như ai đó đã nói trước đó).


-1

SSD không đáng tin cậy như HDD, tốt hơn nên sử dụng nó dưới dạng tệp tạm thời / trang / đầu, thay vì khởi động. Vì bạn có Velociraptor, SSD là không cần thiết.

Tại văn phòng, tôi sử dụng SSD cho đĩa chính của mình và phát triển các ứng dụng C # trên Windows XP, Visual Studio nhanh chóng xây dựng và chạy để gỡ lỗi các dự án của tôi. Tôi cũng sử dụng SSD trên môi trường Hyper-V dưới dạng tệp trang / hoán đổi / temp để lấy hơi. Nếu bạn cần hiệu suất cao hơn, hãy sử dụng eBoostr để lưu trữ hầu hết các tệp được sử dụng, nó cũng làm giảm việc sử dụng ổ cứng, đặc biệt là trên máy chủ web.


1
Tôi không đồng ý với đoạn đầu tiên. SSD Decent, như Vertex 3, nhanh hơn đáng kể so với ổ VelociRaptor. Ví dụ, xem sự khác biệt về thời gian truy cập ở đây . Thật lãng phí khi không sử dụng SSD làm ổ đĩa khởi động / HĐH.
sblair

1
Có, nhưng nó không tăng gấp đôi tốc độ trong thực tế. SSD của tôi đã biến mất. Một người bạn của tôi có SSD, nó đã biến mất. Tôi chỉ tìm kiếm độ tin cậy của SSD; % 2 -hoặc 20? - trong số họ thất bại. Nếu bạn sử dụng nó, sao lưu phân vùng thường xuyên. Tốt hơn nên sử dụng Raptor làm chính và sử dụng eBooster để lưu trữ tệp trên SSD.
Đám mây Nime

1
Một ổ SSD sẽ không tăng gấp đôi tốc độ, nó sẽ tăng tốc độ đọc / ghi ngẫu nhiên lên gần một bậc. Đó là một sự khác biệt đáng chú ý. Có, bộ điều khiển SSD đôi khi có thể bị lỗi (một số dữ liệu gần đây cho thấy tỷ lệ thất bại khoảng 0,5% đến 3%) và về lâu dài bộ nhớ flash sẽ bị hao mòn. Nhưng nó đáng giá.
sblair
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.