Trong báo chí công nghệ không chính thức (tức là báo chí), và trên các blog công nghệ trực tuyến và các diễn đàn thảo luận, người ta thường gặp một lời khuyên giai thoại để không có dung lượng trống trên ổ đĩa cứng hoặc ổ đĩa trạng thái rắn. Nhiều lý do cho việc này được đưa ra, hoặc đôi khi không có lý do nào cả. Như vậy, những tuyên bố này, trong khi có lẽ hợp lý trong thực tế, có một không khí huyền thoại về chúng. Ví dụ:

• Khi (các) đĩa của bạn đã đầy 80%, bạn nên xem xét chúng đầy đủ và ngay lập tức bạn sẽ xóa mọi thứ hoặc nâng cấp. Nếu chúng đạt 90% đầy đủ, bạn nên coi chiếc quần cá nhân của mình đang bốc cháy thực sự và phản ứng với một lượng tức thì thích hợp để khắc phục điều đó. ( Nguồn .)

• Để giữ cho bộ sưu tập rác đạt hiệu quả cao nhất, lời khuyên truyền thống là nhằm mục đích giữ 20 đến 30 phần trăm ổ đĩa của bạn trống. ( Nguồn .)

• Tôi đã được thông báo rằng tôi nên để lại khoảng 20% ​​miễn phí trên HD để có hiệu suất tốt hơn, rằng HD thực sự chậm lại khi gần đầy. ( Nguồn .)

• Bạn nên chừa chỗ cho các tệp hoán đổi và các tệp tạm thời. Tôi hiện đang để lại 33% phần trăm miễn phí và thề sẽ không nhận được dung lượng ổ cứng trống dưới 10 GB. ( Nguồn .)

• Tôi thường nói là 15%, tuy nhiên với các ổ đĩa cứng lớn hiện đang quảng cáo, miễn là bạn có đủ cho các tệp tạm thời và tệp hoán đổi, về mặt kỹ thuật bạn an toàn. ( Nguồn .)

• Tôi sẽ khuyến nghị 10% cộng với trên Windows vì phân mảnh sẽ không chạy nếu không có nhiều thứ miễn phí trên ổ đĩa khi bạn chạy nó. ( Nguồn .)

• Bạn thường muốn để lại khoảng 10% miễn phí để tránh phân mảnh ( Nguồn .)

• Nếu ổ đĩa của bạn luôn đầy hơn 75 hoặc 80 phần trăm, việc nâng cấp lên ổ SSD lớn hơn rất đáng để xem xét. ( Nguồn .)

Đã có nghiên cứu nào, tốt nhất là được công bố trên một tạp chí đánh giá ngang hàng, về tỷ lệ phần trăm hoặc lượng không gian trống tuyệt đối cần thiết bởi sự kết hợp cụ thể của hệ điều hành, hệ thống tệp và công nghệ lưu trữ (ví dụ như đĩa từ so với trạng thái rắn)? (Lý tưởng nhất là nghiên cứu như vậy cũng sẽ giải thích lý do không vượt quá lượng không gian sử dụng cụ thể, ví dụ như để ngăn hệ thống hết dung lượng trao đổi hoặc để tránh mất hiệu suất.)

Nếu bạn biết về bất kỳ nghiên cứu nào như vậy, tôi sẽ rất biết ơn nếu bạn có thể trả lời bằng một liên kết đến nó cộng với một bản tóm tắt ngắn về những phát hiện. Cảm ơn!

Đã có nghiên cứu nào, tốt nhất là được công bố trên một tạp chí đánh giá ngang hàng [Mạnh]?

Người ta phải quay lại hơn 20 năm, về quản trị hệ thống hay nói cách khác, vì điều này. Đây là một chủ đề nóng, ít nhất là trong thế giới của hệ điều hành máy tính cá nhân và máy trạm, hơn 30 năm trước; thời gian mà người BSD đang phát triển Hệ thống tệp nhanh Berkeley và Microsoft và IBM đang phát triển Hệ thống tệp hiệu suất cao.

Tài liệu về cả hai bởi những người tạo ra nó thảo luận về cách thức tổ chức các hệ thống tệp này để chính sách phân bổ khối mang lại hiệu suất tốt hơn bằng cách cố gắng làm cho các khối tệp liên tiếp liền nhau. Bạn có thể tìm thấy các cuộc thảo luận về điều này, và thực tế là số lượng và vị trí của không gian trống còn lại để phân bổ các khối ảnh hưởng đến vị trí khối và do đó hiệu suất, trong các bài viết hiện đại về chủ đề này.

Ví dụ, khá rõ ràng từ mô tả thuật toán phân bổ khối của Berkeley FFS rằng nếu không có không gian trống trong nhóm xi lanh hiện tại và thứ cấp và thuật toán sẽ đạt đến mức dự phòng cấp bốn ("áp dụng tìm kiếm toàn diện cho tất cả các nhóm hình trụ ") hiệu suất phân bổ các khối đĩa sẽ bị ảnh hưởng vì cũng sẽ phân mảnh tệp (và do đó đọc hiệu suất).

Chính những phân tích này và những phân tích tương tự (cách xa các thiết kế hệ thống tập tin duy nhất nhằm cải thiện các chính sách bố trí của các thiết kế hệ thống tập tin thời đó) mà trí tuệ nhận được trong 30 năm qua đã được xây dựng.

Ví dụ: Các câu châm ngôn trong bài báo ban đầu mà khối lượng FFS được giữ dưới 90% đầy đủ, kẻo hiệu suất chịu đựng, được dựa trên các thí nghiệm được thực hiện bởi những người sáng tạo, có thể được tìm thấy không phê phán lặp đi lặp lại ngay cả trong cuốn sách về hệ thống tập tin Unix xuất bản thế kỷ này ^{(ví dụ như Pate2003 trang 216)} . Rất ít người thắc mắc điều này, mặc dù Amir H. Majidimehr thực sự đã làm thế kỷ trước, nói rằng xe trong thực tế không quan sát thấy một hiệu ứng đáng chú ý; không kém phần quan vì cơ chế Unix tục mà bảo rằng thức 10% để sử dụng superuser, có nghĩa là một đầy đủ đĩa 90% là có hiệu quả 100% đầy đủ cho phi superusers nào ^{(Majidimehr1996 p. 68)}. Bill Calkins cũng vậy, người cho rằng trong thực tế, người ta có thể lấp đầy tới 99%, với kích thước đĩa thế kỷ 21, trước khi quan sát hiệu ứng hiệu suất của không gian trống thấp vì thậm chí 1% đĩa kích thước hiện đại cũng đủ để có nhiều không gian trống không bị phân mảnh vẫn để chơi với ^{(Calkins2002 trang 450)} .

Điều này sau là một ví dụ về làm thế nào nhận được sự khôn ngoan có thể trở thành sai. Có những ví dụ khác về điều này. Giống như thế giới SCSI và ATA của địa chỉ khối logic và ghi bit được khoanh vùng thay vì ném ra khỏi cửa sổ tất cả các tính toán cẩn thận về độ trễ quay trong thiết kế hệ thống tệp BSD, do đó, cơ chế vật lý của SSD thay vì bỏ không gian trống nhận được sự khôn ngoan áp dụng cho đĩa Winchester.

Với SSD, toàn bộ dung lượng trống trên thiết bị , tức là trên tất cả các ổ đĩa trên đĩa và ở giữa chúng , có ảnh hưởng cả về hiệu suất và thời gian sử dụng. Và cơ sở cho ý tưởng rằng một tệp cần được lưu trữ trong các khối có địa chỉ khối logic liền kề bị cắt xén bởi thực tế là SSD không có đĩa để xoay và tìm kiếm. Các quy tắc thay đổi một lần nữa.

Với SSD, lượng không gian trống tối thiểu được đề xuất thực sự nhiều hơn 10% truyền thống đến từ các thử nghiệm với đĩa Winchester và Berkeley FFS 33 năm trước. Anand Lal Shimpi cho 25%, ví dụ. Sự khác biệt này được kết hợp bởi thực tế rằng đây phải là không gian trống trên toàn bộ thiết bị , trong khi con số 10% nằm trong mỗi khối FFS duy nhất và do đó bị ảnh hưởng bởi liệu chương trình phân vùng của ai đó có biết TRIM tất cả không gian không phân bổ cho một khối lượng đĩa hợp lệ bởi bảng phân vùng.

Nó cũng được kết hợp bởi các phức tạp như trình điều khiển hệ thống tập tin nhận biết TRIM có thể TRIM dung lượng trống trong ổ đĩa và thực tế là chính các nhà sản xuất SSD cũng đã phân bổ các mức độ khác nhau của không gian dành riêng mà thậm chí không thể nhìn thấy ngoài thiết bị ) cho các mục đích sử dụng khác nhau như thu gom rác và cân bằng hao mòn.

Thư mục

• Marshall K. McKusick, William N. Joy, Samuel J. Leffler và Robert S. Fabry (1984-08). Một hệ thống tệp nhanh cho UNIX . Giao dịch ACM trên hệ thống máy tính. Tập 2 số 3. Trang.181 Từ197. Lưu trữ tại cornell.edu.
• Roy Duncan (1989-09). Thiết kế mục tiêu và thực hiện Hệ thống tệp hiệu suất cao mới . Tạp chí Hệ thống Microsoft . Tập 4 số 5. ​​trang 1 trận13. Lưu trữ tại wisc.edu.
• Marshall Kirk McKusick, Keith Binto, Michael J. Karels và John S. Quarterman (1996-04-30). "Hệ thống tập tin nhanh Berkeley". Thiết kế và triển khai hệ điều hành 4.4 BSD . Addison-Wesley chuyên nghiệp. SỐ 0201549794.
• Cầu Dan (1996-05). Bên trong Hệ thống tệp hiệu suất cao - Phần 4: Phân mảnh, Bitmap đĩa và trang mã . Bit đáng kể. Lưu trữ tại Tạp chí Nhà phát triển điện tử cho HĐH / 2.
• Keith A. Smith và Margo Seltzer (1996). So sánh các chính sách phân bổ đĩa FFS . Kỷ yếu của Hội nghị kỹ thuật thường niên USENIX. Lưu trữ tại harvard.edu.
• Steve D. Pate (2003). "Phân tích hiệu suất của FFS". Hệ thống tập tin UNIX: Tiến hóa, thiết kế và triển khai . John Wiley amp; Con trai Sê-ri YAM471456759.
• Amir H. Majidimehr (1996). Tối ưu hóa UNIX cho hiệu suất . Hội trường Prentice. Mã số 9800131155514.
• Bill Calkins (2002). "Quản lý hệ thống tập tin". Bên trong Solaris 9 . Quê xuất bản. SỐ TIẾNG VIỆT
• Anand Lal Shimpi (2012-10-04). Khám phá mối quan hệ giữa diện tích dự phòng và tính nhất quán hiệu suất trong SSD hiện đại . AnandTech.
• Henry Cook, Jonathan Ellithorpe, Laura Keys và Andrew Waterman (2010). IotaFS: Khám phá tối ưu hóa hệ thống tệp cho SSD . Giao dịch điện tử trên điện tử tiêu dùng. Lưu trữ tại stanford.edu.
• https://superuser.com/a/1081730/38062
• Accela Zhao (2017-04-10). Tóm tắt về SSD & FTL . github.io.
• Windows có cắt không gian không phân chia (không được định dạng) trên ổ SSD không?

Mặc dù tôi không thể nói về "nghiên cứu" được xuất bản bởi "tạp chí đánh giá ngang hàng" - và tôi không muốn phải phụ thuộc vào những công việc hàng ngày - tôi có thể nói về thực tế của hàng trăm sản xuất máy chủ thuộc nhiều hệ điều hành khác nhau trong nhiều năm:

Có ba lý do tại sao một đĩa đầy đủ làm giảm hiệu suất:

• Bỏ đói không gian miễn phí: Hãy nghĩ về các tệp tạm thời, Cập nhật, v.v.
• Suy thoái hệ thống tệp: Hầu hết các hệ thống tệp chịu khả năng bố trí tối ưu các tệp nếu không có đủ chỗ
• Suy giảm cấp độ phần cứng: SSD và đĩa SMR không có đủ dung lượng trống sẽ cho thấy thông lượng giảm và - thậm chí tệ hơn - độ trễ tăng (đôi khi theo nhiều đơn đặt hàng cường độ)

Điểm đầu tiên là tầm thường, đặc biệt là vì không có hệ thống sản xuất lành mạnh nào sẽ sử dụng không gian hoán đổi trong các tệp mở rộng và thu hẹp động.

Điểm thứ hai khác nhau rất nhiều giữa các hệ thống tệp và khối lượng công việc. Đối với một hệ thống Windows có khối lượng công việc hỗn hợp, ngưỡng 70% hóa ra khá dễ sử dụng. Đối với hệ thống tệp ext4 của Linux có ít nhưng tệp lớn (ví dụ: hệ thống phát video), tỷ lệ này có thể lên tới 90 +%.

Điểm thứ ba là phụ thuộc vào phần cứng và phần sụn, nhưng đặc biệt là SSD có bộ điều khiển Sandforce có thể quay trở lại trong việc xóa khối miễn phí trên khối lượng công việc viết cao, dẫn đến độ trễ ghi tăng lên hàng nghìn phần trăm. Chúng tôi thường để lại 25% miễn phí ở cấp phân vùng, sau đó quan sát tỷ lệ lấp đầy dưới 80%.

khuyến nghị

Tôi nhận ra rằng tôi đã đề cập đến cách đảm bảo tỷ lệ lấp đầy tối đa được thi hành. Một số suy nghĩ ngẫu nhiên, không ai trong số họ "đánh giá ngang hàng" (trả tiền, giả mạo hoặc thực tế) mà tất cả đều từ hệ thống sản xuất.

• Sử dụng ranh giới hệ thống tệp: /varkhông thuộc hệ thống tệp gốc.
• Theo dõi, theo dõi, giám sát. Sử dụng một giải pháp làm sẵn nếu nó phù hợp với bạn, nếu không thì phân tích đầu ra df -hvà để chuông báo thức đi trong trường hợp. Điều này có thể giúp bạn tiết kiệm từ 30 hạt nhân trên một fs gốc với các bản nâng cấp tự động được cài đặt và chạy mà không có tùy chọn tự động chuyển.
• Cân nhắc sự gián đoạn tiềm ẩn của tràn fs so với chi phí làm cho nó lớn hơn ngay từ đầu: Nếu bạn không sử dụng thiết bị nhúng, bạn có thể chỉ cần tăng gấp đôi số 4G đó cho root.

Đã có nghiên cứu nào ... về tỷ lệ phần trăm hoặc lượng không gian trống tuyệt đối cần có bởi sự kết hợp cụ thể của hệ điều hành, hệ thống tệp và công nghệ lưu trữ ...?

Trong 20 năm quản trị hệ thống, tôi chưa bao giờ gặp phải nghiên cứu chi tiết các yêu cầu không gian trống của các cấu hình khác nhau. Tôi nghi ngờ điều này là do các máy tính được cấu hình rất đa dạng nên sẽ khó thực hiện do số lượng cấu hình hệ thống có thể có.

Để xác định dung lượng mà một hệ thống yêu cầu, người ta phải tính đến hai biến:

1. Không gian tối thiểu cần thiết để ngăn chặn hành vi không mong muốn, bản thân nó có thể có định nghĩa về chất lỏng.

   Lưu ý rằng chỉ định nghĩa không gian trống cần thiết theo định nghĩa này là vô ích, vì điều đó tương đương với việc nói rằng an toàn khi lái 80 dặm / giờ về phía bức tường gạch cho đến khi bạn va chạm với nó.

2. Tốc độ lưu trữ được tiêu thụ, chỉ ra một lượng không gian thay đổi bổ sung được dự trữ, kẻo hệ thống xuống cấp trước khi quản trị viên có thời gian phản ứng.

Sự kết hợp cụ thể của HĐH, hệ thống tệp, kiến ​​trúc lưu trữ cơ bản, cùng với hành vi ứng dụng, cấu hình bộ nhớ ảo, v.v ... tạo ra thách thức khá lớn đối với một người muốn cung cấp các yêu cầu không gian trống rõ ràng.

Đó là lý do tại sao có rất nhiều "cố vấn" ngoài kia. Bạn sẽ nhận thấy rằng nhiều người trong số họ đưa ra khuyến nghị xung quanh một cấu hình cụ thể. Ví dụ: "Nếu bạn có một ổ SSD có vấn đề về hiệu suất khi gần hết dung lượng, hãy giữ dung lượng trống trên 20%."

Do không có câu trả lời đơn giản cho câu hỏi này, nên cách tiếp cận chính xác để xác định yêu cầu không gian trống tối thiểu của hệ thống của bạn là xem xét các đề xuất chung khác nhau theo cấu hình cụ thể của hệ thống, sau đó đặt ngưỡng, theo dõi và sẵn sàng điều chỉnh nó khi cần thiết

Hoặc bạn chỉ có thể giữ ít nhất 20% dung lượng trống. Tất nhiên trừ khi bạn có khối lượng RAID 6 42 TB được hỗ trợ bởi sự kết hợp giữa SSD và đĩa cứng truyền thống và tệp hoán đổi được phân bổ trước ... (đó là một trò đùa cho những người nghiêm túc.)

Tất nhiên, bản thân một ổ đĩa (ổ cứng hoặc SSD) không quan tâm đến việc có bao nhiêu phần trăm được sử dụng, ngoài SSD có thể xóa không gian trống của chúng cho bạn trước đó. Hiệu suất đọc sẽ hoàn toàn giống nhau và hiệu suất ghi có thể kém hơn một chút trên SSD. Dù sao, hiệu suất ghi không quan trọng trên một ổ đĩa gần đầy, vì không có chỗ để viết bất cứ thứ gì.

Mặt khác, hệ điều hành, hệ thống tập tin và ứng dụng của bạn sẽ mong bạn có sẵn dung lượng trống. 20 năm trước, một ứng dụng điển hình là kiểm tra xem bạn có bao nhiêu dung lượng trên ổ đĩa trước khi cố lưu các tệp của mình ở đó. Ngày nay, ứng dụng tạo các tệp tạm thời mà không cần xin phép bạn, và thường bị sập hoặc hoạt động thất thường khi chúng không làm như vậy.

Hệ thống tập tin có một kỳ vọng tương tự. Ví dụ, NTFS dành một phần lớn đĩa của bạn cho MFT, nhưng vẫn hiển thị cho bạn không gian này là miễn phí. Khi bạn lấp đầy đĩa NTFS của bạn trên 80% dung lượng, bạn sẽ nhận được phân mảnh MFT có ảnh hưởng rất thực đến hiệu suất.

Hơn nữa, có không gian trống thực sự giúp chống lại sự phân mảnh của các tệp thông thường. Các hệ thống tệp có xu hướng tránh phân chia tệp bằng cách tìm đúng vị trí cho mỗi tệp tùy thuộc vào kích thước của tệp. Trên một đĩa gần đầy, họ sẽ có ít tùy chọn hơn, vì vậy họ sẽ phải đưa ra các lựa chọn kém hơn.

Trên Windows, bạn cũng sẽ có đủ dung lượng đĩa cho tệp hoán đổi , có thể phát triển khi cần thiết. Nếu không thể, bạn nên mong đợi các ứng dụng của mình bị đóng cửa cưỡng bức. Có rất ít không gian hoán đổi thực sự có thể làm xấu đi hiệu suất.

Ngay cả khi trao đổi của bạn có kích thước cố định, việc hết hoàn toàn không gian đĩa hệ thống có thể làm sập hệ thống của bạn và / hoặc khiến nó không thể khởi động được (Windows và Linux giống nhau), bởi vì HĐH sẽ có thể ghi vào đĩa trong khi khởi động. Vì vậy, có, đạt 90% mức sử dụng đĩa sẽ khiến bạn coi sơn của mình đang bị cháy. Chưa một lần tôi thấy các máy tính không khởi động đúng cách cho đến khi các bản tải xuống gần đây bị xóa để cung cấp cho HĐH một không gian đĩa nhỏ.

Đối với SSD nên có một khoảng trống còn lại vì tốc độ ghi lại sau đó tăng và ảnh hưởng tiêu cực đến hiệu suất ghi của đĩa. 80% đầy đủ là giá trị an toàn có thể cho tất cả các ổ SSD, một số model mới nhất có thể hoạt động tốt ngay cả với công suất chiếm 90-95%.

https://www.howtogeek.com/165542/why-solid-state-drive-slow-down-as-you-fill-them-up/

Các "quy tắc" khác nhau tùy thuộc vào yêu cầu của bạn. Và có những trường hợp đặc biệt, ví dụ như ZFS: "Với 90% công suất, ZFS chuyển từ tối ưu hóa hiệu suất sang không gian, có ý nghĩa hiệu suất lớn.". Vâng, đây là khía cạnh thiết kế của ZFS ... không phải thứ gì đó có được thông qua quan sát hoặc bằng chứng giai thoại. Rõ ràng, đây không phải là vấn đề nếu nhóm lưu trữ ZFS của bạn chỉ bao gồm SSD. Tuy nhiên, ngay cả với đĩa quay, bạn vẫn có thể vui vẻ đạt 99% hoặc 100% khi bạn xử lý bộ nhớ tĩnh và bạn không cần hiệu suất cao nhất - ví dụ: bộ sưu tập phim yêu thích mọi thời đại của bạn, không bao giờ thay đổi và ở đâu an toàn là ưu tiên 1.

Tiếp theo, btrfs - một trường hợp cực đoan: khi không gian trống quá thấp (một vài MByte), bạn có thể đạt đến điểm không thể quay lại. Không, xóa các tập tin không phải là một lựa chọn, vì bạn không thể. Đơn giản là không đủ không gian để xóa các tập tin. btrfs là một hệ thống tệp COW (sao chép trên ghi) và bạn có thể đạt đến điểm mà bạn không thể sửa đổi siêu dữ liệu nữa. Tại thời điểm này, bạn vẫn có thể thêm bộ nhớ bổ sung vào hệ thống tệp của mình (ổ USB có thể hoạt động), sau đó xóa tệp khỏi hệ thống tệp được mở rộng, sau đó thu nhỏ hệ thống tệp và xóa lại bộ nhớ bổ sung). Một lần nữa, đây là một số khía cạnh gây ra bởi thiết kế của hệ thống tập tin.

Những người có thể cung cấp cho bạn "dữ liệu thực (nghiêm trọng)" có lẽ là những người liên quan đến "lưu trữ thực (nghiêm trọng)". Câu trả lời của Twisty (xuất sắc) đề cập đến mảng lai (bao gồm số lượng lớn quay chậm giá rẻ, nhiều đĩa quay nhanh, nhiều ổ SSD ...) được vận hành trong môi trường doanh nghiệp, nơi yếu tố hạn chế chính là tốc độ của quản trị viên có thể đặt hàng nâng cấp. Đi từ 16T đến 35T có thể mất 6 tháng ... vì vậy, bạn kết thúc với các báo cáo được hỗ trợ nghiêm túc, đề xuất đặt báo thức của bạn lên 50%.

Có rất nhiều, rất nhiều yếu tố góp phần vào kết quả với số lượng rất cụ thể thiết lập. Vì vậy, không có số khó và nhanh, điều này chỉ có thể được đo như là một hàm của các tham số đó. (Đó có thể là lý do tại sao những người dùng khác báo cáo không có nghiên cứu cụ thể về chủ đề cụ thể này được thực hiện - quá nhiều biến để biên dịch bất kỳ kết luận nào.)

• Phần cứng

  • HDD có tất cả các lĩnh vực được phân bổ mọi lúc. Vì vậy, nó hoàn toàn không quan tâm có bao nhiêu trong số chúng chứa dữ liệu người dùng hiện tại. (Đối với bộ điều khiển, tất cả các lĩnh vực đều chứa một số dữ liệu mọi lúc, nó chỉ đọc và ghi đè lên nó như đã nói với.)
  • Mặt khác, bộ điều khiển của SSD, (de) phân bổ các thành phần của nó một cách linh hoạt, gần giống với một hệ thống tệp. Điều này làm cho công việc này khó khăn hơn với việc sử dụng cao hơn. Nó khó hơn bao nhiêu và điều này ảnh hưởng đến hiệu suất có thể quan sát được phụ thuộc vào:
    • Hiệu suất và chất lượng thuật toán của bộ điều khiển
    • Viết tải
    • Trong phạm vi chữ cái, tải tổng thể (để cung cấp thời gian cho bộ điều khiển để thu gom rác)
    • Không gian quá mức (một số nhà sản xuất thậm chí cho phép khách hàng chọn đặt hàng trước hoặc thay đổi linh hoạt)

• Hệ thống tập tin

  • Các hệ thống tệp khác nhau được thiết kế cho các tải khác nhau và yêu cầu xử lý máy chủ. Điều này có thể được điều chỉnh ở một mức độ nào đó bởi các tham số định dạng.
  • Hiệu suất ghi FS là một chức năng của không gian trống và phân mảnh, hiệu suất đọc chỉ là một chức năng của phân mảnh. Nó xuống cấp dần dần ngay từ đầu, vì vậy câu hỏi là ngưỡng chịu đựng của bạn nằm ở đâu.

• Loại tải

  • Tải nặng ghi nhấn mạnh việc nhanh chóng tìm và truy cập các khối miễn phí mới
  • Tải nặng đọc nhấn mạnh việc hợp nhất dữ liệu liên quan để có thể đọc được với ít chi phí hơn

Một điều cần xem xét với các ổ đĩa cơ là thông lượng của cạnh ngoài cao hơn bên trong. Điều này là do có nhiều lĩnh vực trên mỗi cuộc cách mạng cho chu vi bên ngoài lớn hơn.

Khi ổ đĩa đạt đến dung lượng, độ hoàn hảo sẽ giảm vì chỉ có các khu vực bên trong chậm hơn mới có sẵn.

Để biết thêm phân tích chuyên sâu, hãy xem https://superuser.com/a/643634

Nó phụ thuộc vào mục đích sử dụng của ổ đĩa, nhưng nói chung, dung lượng trống 20% ​​đến 15% là một câu trả lời tốt cho đĩa quay và 10% trở lên là tốt cho SSD.

Nếu đây là ổ đĩa chính trên máy tính và các tệp có thể được di chuyển, thì 20% dung lượng trống sẽ ngăn chặn sự chậm lại đáng kể. Điều này sẽ cho phép đủ không gian mở trong toàn bộ ổ đĩa để dữ liệu được di chuyển và sao chép khi cần thiết. Ổ đĩa quay sẽ hoạt động tốt nhất khi các vị trí miễn phí gần với dữ liệu gốc hơn, trong khi trong ổ SSD, vị trí thực tế không ảnh hưởng đến hiệu suất hàng ngày. Vì vậy, ổ đĩa quay nên có nhiều không gian trống hơn vì lý do hiệu suất hoàn toàn. Trên SSD, dung lượng trống giảm sẽ làm giảm tuổi thọ ổ đĩa, nhưng nó sẽ không làm giảm hiệu suất. SSD cố gắng lưu trữ dữ liệu tạm thời và các tệp tải xuống ngẫu nhiên ở các vị trí ít được sử dụng nhất để chúng có thể cân bằng việc sử dụng tế bào trên toàn bộ ổ đĩa; nếu không, một phần của ổ đĩa sẽ già đi nhanh hơn nhiều so với phần còn lại của nó.

Nếu đây là ổ đĩa lưu trữ đa phương tiện hoặc dài hạn, thì 5% đến 10% miễn phí là đủ, và 10% sẽ tốt hơn nếu đó là đĩa quay. Bạn không cần nhiều dung lượng trống vì ổ đĩa này sẽ hiếm khi yêu cầu dữ liệu được di chuyển, do đó hiệu suất không phải là một yếu tố quan trọng. Không gian trống là hữu ích chủ yếu để cho phép các thành phần xấu bị loại bỏ và thay thế, và cho phép các tệp được liền kề hơn.

Tôi sẽ không đẩy bất kỳ ổ đĩa nào vượt quá 95% công suất trong hơn một ngày trừ khi có lý do rất rõ ràng.