Ổ SSD có được hưởng lợi từ kích thước đơn vị phân bổ không mặc định không?


19

Kích thước đơn vị phân bổ mặc định được đề xuất khi định dạng ổ đĩa trong thiết lập hiện tại của chúng tôi là 4096 byte. Tôi hiểu những điều cơ bản về ưu và nhược điểm của kích thước lớn hơn và nhỏ hơn (tăng hiệu suất so với bảo toàn không gian) nhưng có vẻ như lợi ích của ổ đĩa trạng thái rắn (tìm kiếm thời gian thấp hơn so với đĩa cứng) có thể tạo ra tình huống phân bổ nhỏ hơn nhiều kích thước không gây bất lợi.

Đây có phải là trường hợp ít nhất sẽ giúp khắc phục nhược điểm của SSD (giá cao hơn trên mỗi GB).

Có cách nào để xác định 'chi phí' của các kích thước phân bổ nhỏ hơn liên quan cụ thể đến thời gian tìm kiếm không? Hoặc có bất kỳ nghiên cứu hoặc bài viết nào đề xuất thay đổi từ mặc định dựa trên công nghệ mới hơn này không?

(Giả sử sự phân tán trung bình nhất của các tệp chương trình kích thước, tệp hệ điều hành, dữ liệu, mp3, tệp văn bản, v.v.)

Câu trả lời:


8

Nếu bạn đang tìm kiếm một bài viết tốt, tôi khuyên bạn nên

The Hows and Whys of SSD của Robert Hallock

Tôi đã liên kết đến trang 2, trong đó có phần thảo luận về phân cụm và kích thước khối.

[...] Giải pháp cho vấn đề này là tăng kích thước cụm, trong đó có một số lợi thế:

  • Giảm độ phức tạp của hệ thống tập tin; ít cụm có nghĩa là ít tổ chức hơn.
  • Tăng tốc độ đọc và ghi khi kích thước cụm tiếp cận ngang bằng với kích thước khối.
  • Giảm không gian chùng nếu hệ thống chủ yếu bao gồm các tệp lớn.

Tuy nhiên, kích thước cụm tăng không phải là một viên đạn ma thuật cho các đĩa trạng thái rắn, vì hầu hết mọi người đều có sự pha trộn thông tin. Các trò chơi thường chứa vô số các tệp nhỏ và hệ điều hành là tổng của các tệp nhỏ gần như là một quy tắc; nhưng phim ảnh, âm nhạc, tài liệu lưu trữ và MMO là những ứng cử viên hoàn hảo cho kích thước cụm mở rộng. Khó chịu hơn neo của các cụm nhỏ là quá trình phức tạp để có được các cụm lớn hơn trong các hệ điều hành Windows hiện đại. Một kỳ công như vậy đòi hỏi phải sử dụng trước các chương trình như Acronis Disk Director, có thể tăng kích thước cụm trước khi cài đặt Windows. Cũng có thể thay đổi kích thước các cụm hiện có, nhưng một quy trình như vậy được thực hiện với mức độ thành công đáng sợ khác nhau.


6

Tôi hoàn toàn đồng ý với Hollock (" Cách thức và lý do của SSD ") khi nói đến hiệu suất tăng khi kích thước cụm tiếp cận kích thước khối. Trong tình huống như vậy, bạn sẽ có số lần đọc khối và chi phí tối thiểu cho mỗi yêu cầu cụm.

Có kích thước cụm nhỏ hơn kích thước khối không nhất thiết phải là một cú đánh hiệu suất lớn nhưng nó thường sẽ đòi hỏi nhiều chi phí hơn (vì SSD sẽ đọc khối và XÓA phần của khối không nằm trong cụm được yêu cầu. Điều này thậm chí còn tệ hơn nếu ổ đĩa bị phân mảnh và các cụm liền kề trên cùng một khối không phải là một phần của cùng một tệp.)

Nói chung, việc tăng kích thước cụm lên (nhưng không vượt quá) kích thước khối của SSD sẽ có lợi. Mất mát (tất nhiên) là bạn sẽ bắt đầu mất dung lượng và như bạn đã đề cập, ổ SSD $ / GB cao hơn nhiều so với phương tiện truyền thông từ tính.

Tùy thuộc vào số tiền bạn có, bạn có thể: 1) Đặt kích thước cụm thành kích thước khối ổ đĩa của bạn (như Hollock đề cập có thể hơi tẻ nhạt) và gặt hái các lợi ích hiệu suất trong khi hy sinh không gian và phải chi nhiều hơn $$

hoặc là

2) Đặt kích thước cụm thành kích thước của tệp trung bình (hoặc cao hơn một chút để biến nó thành một yếu tố của kích thước khối) trên ổ đĩa của bạn để cải thiện dung lượng ổ đĩa trong khi (có khả năng) hy sinh một số hiệu suất. Nếu kích thước cụm nhỏ hơn đáng kể so với kích thước khối, hãy đảm bảo giữ cho ổ đĩa được chống phân mảnh.

Hy vọng điều này sẽ giúp :)




3

Cả hai câu trả lời của bạn (và của Hallock) đều mâu thuẫn với việc Giảm khuếch đại Viết có nghĩa là gì để thực hiện - đó là giảm hao mòn NAND không cần thiết. Tăng kích thước cụm có nghĩa là lãng phí ghi vào đĩa. Chống phân mảnh ổ SSD bạn nói? Đó là một trong những tội lỗi chết người khi sử dụng SSD.

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.