Hỏi / Đáp Ổ SSD SATA Crucial MX500 500GB - - - Tuổi thọ còn lại giảm nhanh mặc dù chỉ có vài byte được ghi vào ?

Tuổi thọ còn lại (RL) của ổ cứng SSD Crucial MX500 của tôi đã giảm nhanh chóng, mặc dù máy tính không ghi nhiều dữ liệu vào ổ cứng. Dưới đây là nhật ký mà tôi bắt đầu ghi lại sau khi nhận thấy RL đạt 95% sau khoảng 6 tháng sử dụng.
Giả sử RL thực sự phụ thuộc vào số byte được ghi, thì tốc độ giảm RL đang tăng tốc và có điều gì đó rất không ổn. Giảm RL mới nhất, từ 94% xuống 93%, xảy ra sau khi chỉ ghi 138 GB trong 20 ngày.
(Lưu ý 1: Sau khi RL đạt 95%, tôi đã thực hiện một số bước để giảm các lần ghi "không cần thiết" vào ổ SSD bằng cách di chuyển một số tệp thường xuyên ghi vào ổ cứng, ví dụ như thư mục hồ sơ Firefox. Đó là lý do tại sao chỉ có 528 GB được ghi vào ổ SSD kể từ ngày 23 tháng 12, mặc dù máy tính được đặt thành Không bao giờ ngủ và luôn bật nguồn. Lưu ý 2: Sau khi máy tính và ổ SSD được khoảng 2 tháng tuổi, vào khoảng tháng 9, tôi đã thay đổi cấu hình nguồn của máy tính để nó Không bao giờ ngủ. Lưu ý 3: Ổ SSD vẫn còn nhiều dung lượng trống; chỉ có 111 GB trong tổng dung lượng 500 GB của nó bị chiếm dụng. Lưu ý 4: Ba tiện ích phần mềm khác nhau đồng ý về số liệu: Crucial's Storage Executive, HWiNFO64 và CrystalDiskInfo. Lưu ý 5: Storage Executive cũng cho thấy Tổng số byte được ghi không lớn hơn nhiều so với Tổng số ghi trên máy chủ, ngụ ý rằng khuếch đại ghi không phải là yếu tố quan trọng.)

Tôi hiểu là Tuổi thọ còn lại được cho là phụ thuộc vào số byte được ghi, nhưng có vẻ như ổ đĩa báo cáo một giá trị phụ thuộc chủ yếu vào số giờ bật nguồn. Ai đó có thể giải thích điều gì đang xảy ra không? Tôi có hiểu sai ý nghĩa của Tuổi thọ còn lại không? Về cơ bản, nó không phải là từ đồng nghĩa với sức bền sao?

�

Kiểm tra các giá trị SMART 247 (F7) và 248 (F8) vì chúng sẽ cho phép bạn tính toán khuếch đại ghi. Kiểm tra trang. 25-26 tại đây để biết thêm thông tin. Bạn cũng có thể kiểm tra xem có khối dự phòng nào được sử dụng không, v.v., nhưng nhìn chung tôi không quan tâm lắm.

@Maxxify, cảm ơn bạn đã trả lời nhanh như vậy. Tôi đã sử dụng công thức cho Hệ số khuếch đại ghi ở trang 26 của tài liệu Micron để tính toán Hệ số khuếch đại ghi:

Ngày	Tổng số lần ghi của máy chủ (GB)	S.M.A.R.T. F7	S.M.A.R.T. F8	WAF = (F7+F8)/F7	Tổng số lần ghi được khuếch đại (GB)
02/06/2020	6.323	219.805.860	1.229.734.020	6,59	41.698

Lưu ý: Kích thước của Theo một bài báo học thuật dài 9 trang năm 2019 mà tôi tìm thấy bằng cách tìm kiếm trên Google 'nand page size critical mx500' ("Tại sao và cách tăng độ trong suốt của hiệu suất SSD" tại http://www.cs.technion.ac.il/~dan/papers/frvrs-hotos-2019.pdf ). Tương tự như tỷ lệ Tổng số lần ghi trên máy chủ so với SMART F7 ở trên, khoảng 29 KB.

Liệu WAF 6,59 có lớn bất thường không đối với ổ SSD hầu như trống và không có nhiều lần xóa?
Bạn có thể giải thích sự gia tốc của việc giảm Tuổi thọ còn lại so với số byte đã ghi không?

Bây giờ tôi đã biết WAF, tôi cho rằng Tổng số byte đã ghi được hiển thị bởi Storage Executive thực sự giống với Tổng số lần ghi trên máy chủ. Nó chỉ cần sử dụng một đơn vị khác khiến nó có vẻ lớn hơn một chút, giống như cách một MByte lớn hơn 1 triệu byte. Thật đáng buồn khi Storage Executive không hiển thị Tổng số lần ghi bao gồm khuếch đại.

Tôi cho rằng khuếch đại ghi có thể được cải thiện bằng cách lưu vào bộ đệm ghi. Chính sách bộ đệm ghi của Windows 10 là cài đặt mặc định của nó: Đã bật, với chức năng xóa bộ đệm Không tắt. Tôi cho rằng Momentum Cache có thể làm tốt hơn bộ đệm Windows để giảm khuếch đại ghi, nhưng tôi không thể "kích hoạt" Momentum Cache và không có gợi ý nào từ bộ phận hỗ trợ kỹ thuật có thể xác định lý do tại sao. (Trong email gần đây nhất của họ, sau một vài tuần im lặng, họ hỏi rằng máy tính của tôi có bộ nguồn không bị gián đoạn không -- có -- và yêu cầu tôi chạy hai bài kiểm tra tự động trong Storage Executive -- cả hai đều thành công. Đang chờ xem họ có ý tưởng nào khác không và liệu họ có bao giờ phản hồi mối quan tâm của tôi về việc Tuổi thọ còn lại đang giảm nhanh không.)

Tại sao bạn lại không "lo lắng nói chung?" Nếu lý do là vì bạn có khả năng thay thế phần cứng thường xuyên thì không phải là chung chung. Tôi không có nhiều thu nhập nên tôi muốn phần cứng của mình tồn tại trong NHIỀU năm. Và tôi không muốn trở thành nạn nhân của lỗi đọc trong vài năm. (Vì lý do tương tự, tôi đã đặt BIOS để ép xung CPU & DRAM và giảm mức tiêu thụ điện năng CPU tối đa & điện áp DRAM.)

Cảm ơn bạn một lần nữa vì sự giúp đỡ của bạn!

Kiểm tra các giá trị SMART 247 (F7) và 248 (F8) vì chúng sẽ cho phép bạn tính toán khuếch đại ghi. Kiểm tra trang 25-26 tại đây để biết thêm thông tin. Bạn cũng có thể kiểm tra xem có khối dự phòng nào được sử dụng không, v.v., nhưng nhìn chung tôi không quan tâm lắm.

Nhấn để mở rộng...

Trong bài báo pdf mà tôi đã liên kết trong bài đăng ngày hôm qua có một biểu đồ cho thấy Hệ số khuếch đại ghi cho ổ SSD Crucial MX500, được đo bằng năm loại khối lượng công việc ghi. WAF đo được dao động từ khoảng 0,3 đến 1,2. Các giá trị đó ÍT HƠN NHIỀU so với 6,59 mà MX500 của tôi đã trải qua. Có vẻ như MX500 của tôi không hoạt động bình thường. Điều gì có thể giải thích cho sự kém hiệu quả ghi khủng khiếp của nó? (Lưu ý: Biểu đồ nằm ở góc trên bên trái của trang 4 của bài báo.)

Khi tìm kiếm trên Google, tôi tìm thấy một bài báo của Micron về Hệ số khuếch đại ghi, trong đó cũng thảo luận về cách tính WAF "gần đây", bằng cách theo dõi mức tăng của SMART F7 & F8 theo thời gian và sử dụng mức tăng trong công thức. (Bạn có thể tìm thấy bài báo bằng cách tìm kiếm tiêu đề của nó trên Google: "tnfd23_m500_smart_attributes_calc_waf.pdf".)
Công thức cho WAF gần đây là:
1 + ΔF8/ΔF7
trong đó ΔF7 và ΔF8 là mức tăng của F7 và F8 trong khoảng thời gian gần đây.

Tôi đã áp dụng công thức đó trong ngày gần đây nhất -- tương đương với 24 giờ gần đây nhất -- và WAF trong ngày gần đây nhất là 56,79 !!! Có vẻ như quá lớn. Xem ba cột ngoài cùng bên phải trong bảng sau (bạn có thể cần cuộn sang bên phải để xem chúng):

Ngày

Tổng số lần ghi vào máy chủ (GB)

S.M.A.R.T. F7

S.M.A.R.T. F8

WAF = 1 + F8/F7

Tổng số lần ghi được khuếch đại (GB)

ΔF7

ΔF8

WAF gần đây = 1 + ΔF8/ΔF7

Điều gì có thể khiến WAF cao như vậy??

Tôi có một giả thuyết để kiểm tra, về lý do tại sao WAF lại cao như vậy. Bộ nhớ đệm Momentum trong Storage Executive đã "không thể kích hoạt" kể từ khi tôi cài đặt Storage Executive nhiều tuần trước. (Bộ phận hỗ trợ kỹ thuật của Crucial/Micron không thể tìm ra lý do tại sao nó không kích hoạt và tôi không biết liệu họ đã từ bỏ việc thử hay chưa.) Giả thuyết của tôi là trình điều khiển bộ nhớ đệm Momentum Cache đã ngăn bộ nhớ đệm ghi của Windows 10 hoạt động, khiến tất cả các lần ghi được thực thi ngay lập tức, thay vì cho phép nhiều lần ghi được tổng hợp lại thành các lần ghi tuần tự lớn.

Để thử kiểm tra giả thuyết này, hôm nay tôi đặt Storage Executive thành "vô hiệu hóa" Bộ nhớ đệm Momentum, điều này dường như đã dẫn đến việc trình điều khiển bộ nhớ đệm bị xóa, theo thông báo hiển thị trước khi khởi động lại máy tính. Trong những ngày và tuần tới, thỉnh thoảng tôi sẽ ghi lại các giá trị SMART F7 và F8 và tính toán WAF gần đây. (Xem bài đăng trước của tôi về cách đo "WAF gần đây").

Nếu trình điều khiển Momentum Cache "chưa được kích hoạt" chịu trách nhiệm cho WAF lớn một cách thái quá thì đây là lỗi không thể chấp nhận được.

Tôi biết về bài báo đó. Nó có một số thiếu sót nhưng tôi sẽ trình bày chi tiết một cách nhanh chóng. Kích thước trang của flash Micron là 16KB thô, nhưng luôn có dữ liệu dự phòng/ECC trong số những thứ khác. Ngoài ra, tôi thường đặt WAF của người tiêu dùng trong phạm vi 1,5-2,0. Mặc dù chắc chắn có thể đạt dưới 1,0 với nén, nhưng khả năng tăng tốc ghi động (SLC động) của Micron chỉ có thể có hệ số cộng từ 0 đến 2, nó sẽ không đưa WAF xuống dưới 1,0. Tuy nhiên, theo tôi, bất kỳ thứ gì trên khoảng 2,0 đều được coi là cao. Về mặt kỹ thuật, WAF là 1 + chênh lệch ghi (248/247) vì một lần nữa, không nén ngụ ý 1,0 là tốt nhất.

Khi nói không lo lắng về điều đó, ý tôi là: các ổ đĩa này có thể chịu được một tấn ghi, trong phạm vi PB. Có khả năng nó sẽ hỏng ở nơi khác. Tôi đã đề cập đến chủ đề chính xác này với những người sở hữu SSD khác trước đây. Điều đó nói rằng... Momentum Cache không khác gì RAPID Mode của Samsung, một thứ hoàn toàn nhảm nhí. Tất cả những gì nó làm là sử dụng RAM hệ thống để lưu trữ đệm. Hệ điều hành của bạn đã làm điều đó, bạn chỉ đang thêm chi phí. Kỹ thuật này đã lỗi thời. Bạn không bao giờ muốn chạy nó trừ khi trong những trường hợp rất đặc biệt. Tôi sẽ phải xem liệu tôi có thể tìm thấy người gặp vấn đề giống bạn trên Reddit không vì tôi kết luận đó là lỗi ngủ/ngủ đông, tôi không nghĩ anh ta đề cập đến việc sử dụng MC...

Trừ khi thuật ngữ của Micron gây hiểu lầm, phương trình "NAND_Page_Size = Total_Host_Writes / F7" ngụ ý rằng kích thước trang xấp xỉ là 29 KByte. (6.329 GB / 220.037.004 xấp xỉ là 28,8 KByte).

Tôi đã tiếp tục ghi lại các số S.M.A.R.T.: Tổng số lần ghi của máy chủ, F7 và F8. Trong 24 giờ gần nhất, WAF xấp xỉ là 39,6 (và trong 48 giờ gần nhất là xấp xỉ 47,7). Trong hầu hết 24 giờ gần nhất, trình điều khiển Momentum Cache đã bị xóa, điều này có thể giải thích một phần lý do khiến WAF giảm từ 56,8 một ngày trước xuống còn 39,6 hôm nay. Nhưng 39,6 vẫn có vẻ lớn một cách thái quá.

Tôi cũng đã bắt đầu ghi lại Số lần xóa khối trung bình (ABEC), có vẻ như có liên quan chặt chẽ đến tuổi thọ còn lại của ổ đĩa SSD. Ngày nay, ABEC hiện tại là 93 và ABEC thô là 108. Với công thức trong tài liệu Thuộc tính S.M.A.R.T. của Micron, ABEC hiện tại có vẻ giống với Tuổi thọ còn lại (93%) vì ABEC hiện tại được chuẩn hóa theo tuổi thọ định mức của một khối:
ABEC hiện tại = 100 x (1 - AverageEraseCount/RatedEraseCount).
ABEC thô là số lần xóa trung bình của tất cả các siêu khối, trong đó một siêu khối bao gồm các khối có cùng số trên tất cả các mặt phẳng. Tôi không biết ổ SSD có bao nhiêu mặt phẳng, nhưng 108 có vẻ quá lớn đối với ổ SSD 500 GB đã ghi 6.329 GB byte máy chủ vào đó.

Tôi không chắc rằng ổ SSD sẽ hỏng do một số nguyên nhân khác trước khi nó hỏng do khuếch đại ghi quá mức. Nguyên nhân nào khác có thể khiến nó hỏng trước khi khuếch đại ghi giết chết nó? Nhiệt độ trung bình của nó dưới 35C và nhiệt độ đỉnh của nó hiếm khi vượt quá 45C. (Nó được gắn trong vỏ máy ngay phía sau quạt hút tốc độ không đổi và hệ số dạng SATA 2,5" của nó có diện tích lớn hơn hệ số dạng M.2 để tản nhiệt.)

Tôi không thấy nguyên nhân gây ra hiện tượng khuếch đại ghi cao có thể là lỗi ngủ/ngủ đông. Nhiều tháng trước, khoảng hai tháng sau khi máy tính và ổ SSD mới vào mùa hè năm ngoái, tôi đã đặt máy tính không bao giờ ngủ. Cụ thể, chế độ nguồn điện đang hoạt động của Windows là "không bao giờ ngủ", "không bao giờ ngủ đông" và "tắt ổ cứng sau 0 phút". (Tôi hiểu là "0 phút" có nghĩa là không bao giờ.) Có lẽ bạn đang ám chỉ đến tính năng DevSleep của ổ SSD?

Kích thước trang thực tế có thể là 16KB nhưng nó khác nhau tùy thuộc vào flash - ví dụ, 32L/384Gb của họ sử dụng kích thước trang 24KB. Kích thước thực tế lớn hơn 2208B đối với ECC/diện tích dự phòng trong trường hợp đó.

Đúng vậy, tuổi thọ có thể được xác định bởi P/E liên quan trực tiếp đến số lần xóa khối. Không chắc Micron theo dõi nó như thế nào nhưng thường thì đó là số lần xóa trung bình thẳng trên mỗi khối được chuyển đổi trực tiếp thành P/E, được đưa ra dưới dạng hex. Vì vậy, 108 = 264 P/E, (264)/(0,07) = 3771 nhưng có lẽ nó được đặt ở mức 3500 P/E. Tôi có NS200 (cùng phần cứng với MX500) và đây là SMART 167 (A7) nhưng có thể là 168 (A8) trên MX500. Chắc chắn là WAF rất cao trong trường hợp đó (~20).

Bộ điều khiển luôn tự hỏng hoặc các thành phần khác bị hỏng/ngắn mạch. Mất điện/sập nguồn cũng là phương pháp chính làm hỏng ổ đĩa do bản chất dễ bay hơi của DRAM và chỉ cần ánh xạ nói chung. Nhiệt độ không phải là vấn đề chính. Vấn đề với chế độ ngủ/ngủ đông là nó sẽ ghi RAM vào đĩa và điều này có thể có WAF cao nếu thực hiện nhiều lần hoặc không đúng cách và nhiều thiết bị gặp sự cố với chế độ ngủ. Vâng, rõ ràng là việc tắt chế độ ngủ khiến điều này không có khả năng xảy ra hoặc không thể xảy ra, nhưng nó thường liên quan đến cài đặt nguồn điện (theo lý thuyết). Các vấn đề khác có thể là Windows phát hiện ra nó là ổ cứng (không có khả năng xảy ra) để tối ưu hóa, phân trang không đúng cách, những thứ tương tự như vậy. Thành thật mà nói, đây không phải là sự cố phổ biến mà tôi từng thấy và tôi không biết tại sao một số ổ đĩa lại gặp phải sự cố này. MX500 dựa vào khả năng tăng tốc ghi động của Micron (về cơ bản là SLC động) có thể có hệ số cộng cho WAF nhưng không bao giờ vượt quá 2. Vì vậy, bạn sẽ có các lệnh ghi được cam kết với TLC rồi ghi lại nhiều lần (SLC sẽ trì hoãn các lệnh ghi).

WAF sẽ bị ảnh hưởng như thế nào khi đĩa đầy khi không có TRIM? Việc không có TRIM có thể giải thích được vấn đề của OP không?

Có thể sẽ thú vị khi xem WAF gia tăng có tăng lên nếu TRIM bị vô hiệu hóa không.

WAF sẽ bị ảnh hưởng như thế nào khi ổ đĩa đầy nếu không có TRIM? Việc không có TRIM có thể giải thích được vấn đề của OP không?

Có thể sẽ rất thú vị khi xem WAF gia tăng có tăng lên nếu TRIM bị vô hiệu hóa không.

Nhấn để mở rộng...

Vâng, tôi đã đề cập đến việc kiểm tra để chắc chắn rằng Windows nhận dạng ổ đĩa là SSD để tối ưu hóa. Về cơ bản, Windows sẽ cắt lại trong quá trình tối ưu hóa nếu đúng là như vậy (TRIM/UNMAP cho tất cả các sector chưa sử dụng). Tất nhiên bạn có thể xác minh xem TRIM có được bật hay không, nhưng bạn đúng khi nói rằng TRIM giúp giảm khuếch đại ghi vì nó giúp thu gom rác và giảm ghi trang không cần thiết. Các hoạt động này được thực hiện khi nhàn rỗi (ở chế độ nền) nên ổ đĩa được duy trì sử dụng liên tục sẽ là một vấn đề khá lớn, nhưng điều đó cũng có thể liên quan đến trạng thái nguồn. Vì vậy, nó sẽ làm trầm trọng thêm vấn đề.

TRIM được bật và ReTrim được lên lịch một lần mỗi tuần.
Giá trị 108 mà tôi đã đề cập ở trên cho Số lượng xóa khối trung bình RAW là hệ cơ số 10, không phải hệ cơ số 16.

"Vô hiệu hóa" (xóa) trình điều khiển Momentum Cache "không hoạt động", mà tôi đã thực hiện vào thứ Sáu, vẫn chưa có tác dụng. Dưới đây là dữ liệu trong ba ngày qua, cho thấy -- hãy xem cột màu đỏ, bạn có thể cần phải cuộn sang bên phải -- rằng WAF là 68,87 trong khoảng thời gian 24 giờ gần đây nhất:

Ngày	Tổng số lần ghi vào máy chủ (GB)	S.M.A.R.T. F7	S.M.A.R.T. F8	WAF = 1 + F8/F7	Tổng số lần ghi được khuếch đại (GB)	ΔF7 (1 hàng)	ΔF8 (1 hàng)	WAF gần đây = 1 + ΔF8/ΔF7	ΔF7 (2 hàng)	ΔF8 (2 hàng)	WAF gần đây (2 hàng) = 1 + ΔF8/ΔF7
02/06/2020

Một email ngày hôm qua từ bộ phận hỗ trợ kỹ thuật của Micron không đưa ra lời khuyên hữu ích nào: "Đối với sự cố bộ nhớ đệm động lượng, vì bạn đã thực hiện tất cả các bước khắc phục sự cố, tôi khuyên bạn nên thử gỡ cài đặt bộ điều hành Crucial Storage rồi cài đặt lại. Vấn đề có thể nằm ở phần quản lý nguồn điện trên hệ thống của bạn hoặc ở Storage executive. Đối với phần trăm giảm, có thể là do đọc và ghi liên tục từ SSD. Tuy nhiên, đối với cả hai vấn đề nếu vẫn tiếp diễn, bạn có thể bỏ qua việc sử dụng Crucial storage executive và sử dụng bất kỳ phần mềm 'giám sát và kiểm soát' SSD của bên thứ 3 nào khác cho bộ nhớ đệm động lượng."

Lời khuyên của họ không hữu ích vì:
(1) Tôi đã thử gỡ cài đặt/cài đặt lại Storage Executive nhiều tuần trước (lần đầu tiên họ gợi ý như vậy).
(2) Có vẻ vô lý khi cho rằng phần trăm giảm nhanh chóng trong Tuổi thọ còn lại có thể là do "đọc và ghi liên tục" vì ổ SSD của tôi được ghi ít hơn nhiều so với hầu hết mọi người ghi vào ổ SSD của họ. HWiNFO cho thấy Tốc độ ghi trung bình thấp hơn 0,1 MByte/giây trong nhiều tuần (chỉ tổng cộng 19 GB trong ba ngày qua, theo mức tăng của Tổng số ghi trên máy chủ từ 6.323 GB vào ngày 6 tháng 2 lên 6.342 GB vào ngày 9 tháng 2) và đôi khi hiển thị Tốc độ ghi hiện tại là 0. Tốc độ đọc trung bình vào khoảng 0,22 MByte/giây và Tốc độ đọc hiện tại đôi khi là 0.
(3) Họ không chỉ rõ phần mềm 'giám sát và điều khiển' SSD của bên thứ ba nào có thể tương thích với MX500.

Để tham khảo, bo mạch chủ là MSI X470 Gaming Plus, CPU là Ryzen 3 3200G và hệ thống có 16 GB (2 x 8 GB) Corsair Vengeance 3200 dram (giảm xung nhịp ở mức 2400 nên sẽ chạy ở mức 1,2 V). Không có card đồ họa nào được cài đặt vì CPU là APU.

Có lẽ trình điều khiển của bên thứ ba đang gây ra sự cố? VMware Player đã được cài đặt từ mùa hè năm ngoái và mặc dù tôi hiếm khi chạy máy ảo nữa, VMware Player đã tự cài đặt một số bản cập nhật. Có lẽ trình điều khiển đĩa ảo bị lỗi có thể can thiệp vào ổ SSD ngay cả khi Player không chạy máy ảo?

Phần mềm theo dõi dữ liệu S.M.A.R.T. có thể can thiệp vào ổ SSD không? Một lúc trước, tôi đã thoát HWiNFO và CrystalDiskInfo, những chương trình này thường chạy 24 giờ mỗi ngày. Trong một hoặc hai ngày nữa, tôi có thể kiểm tra WAF gần đây để xem nó có bị ảnh hưởng do không chạy chúng không.

Có thể chương trình cơ sở ổ SSD bị lỗi khi ghi máy chủ ít hơn nhiều so với thông thường không? Có thể đây là trường hợp sử dụng mà Crucial/Micron chưa từng thử nghiệm. Khoảng hai tháng trước, khi Tuổi thọ còn lại đạt 95%, tôi đã thực hiện các bước để giảm đáng kể việc ghi vào máy chủ (di chuyển hồ sơ Firefox sang ổ cứng, thiết lập simlink để UPS CyberPower ghi nhật ký vào ổ cứng thay vì ổ SSD, tắt chức năng quét phần mềm diệt vi-rút của Comodo trong các tệp nén, v.v.) nhưng tốc độ giảm Tuổi thọ còn lại đã tăng tốc kể từ đó. Trong khoảng 7 tháng sử dụng ổ SSD, WAF của ổ SSD trung bình là 6,75 (giá trị ngày 9 tháng 2 trong bảng ở trên), thấp hơn một bậc so với giá trị WAF của những ngày gần đây. Tuy nhiên, đây có thể là sự trùng hợp ngẫu nhiên vì Windows, trình điều khiển MSI và các phần mềm khác đã nhận được các bản cập nhật có thể chịu trách nhiệm.

Bạn có gợi ý nào về những gì tôi nên thử không?

Yêu cầu thay thế ổ SSD theo chế độ bảo hành có hợp lý không?

108 sau đó sẽ là 108 P/E, điều này hợp lý hơn vì % sức khỏe của NS200 của tôi dựa trên 1500 P/E: (100/7)(108) = 1543. Vì vậy, ít nhất thì có vẻ đúng. Mặc dù đèn flash này tốt hơn nhiều so với con số đó, ít nhất là 3000 và hơn 5-10K tùy thuộc vào các yếu tố khác. Vì vậy, đúng là sử dụng rất nhiều trong sáu tháng, nhưng nó vẫn có thể tồn tại hơn một thập kỷ.

Tôi không có lời khuyên nào thêm vào lúc này. Để theo dõi, tôi sử dụng Hard Disk Sentinel.

nó có wty 5 năm và được đánh giá là 180TBW - vì vậy không cần phải hoảng sợ ngay bây giờ.thậm chí giảm 1% mỗi tháng, bạn đang nói về chu kỳ hoạt động 8 năm.

Bạn luôn có thể RMA sau này nếu RL trở nên thực sự đáng báo động.

việc thường xuyên di chuyển các tệp sang HDD có thể không giúp ích nếu TEMP: của bạn vẫn là SSD - nó vẫn là một pass-thru.

Ngoài ra, việc để máy tính bật so với tạm dừng không quan trọng vì điều đó được thực hiện với bộ nhớ. Chế độ ngủ đông sẽ khác. Trên thực tế, việc bật nó sẽ cho phép ghi/cập nhật nền nhiều hơn là tạm dừng.

Tôi sẽ kiểm tra xem bạn đang sử dụng bao nhiêu tệp trang và không gian khôi phục được đặt thành bao nhiêu, bạn có thể đang ghi lại nhiều hơn mức cần thiết.

Tôi cũng sẽ kiểm tra chương trình cơ sở Crucial và đảm bảo rằng bạn không sử dụng chương trình cơ sở kém, đồng thời kiểm tra xem cài đặt AHCI có chính xác không (giả sử là đúng nếu TRIM đang hoạt động)

để đưa ra quan điểm, bạn đã ghi 6,2TB / 180 = ~3,5% (so với 5% tương đối không đáng kể).

Máy ảo sử dụng rất nhiều không gian SSD nên điều đó có thể làm hỏng bất kỳ thuật toán nào mà SSD đang sử dụng cho RL. Nhưng giá trị gần với những gì bạn mong đợi về mặt thống kê

TRIM được bật và ReTrim được lên lịch một lần mỗi tuần.

Giá trị 108 mà tôi đã đề cập ở trên cho Số lần xóa khối trung bình RAW là cơ số 10, không phải cơ số 16.

"Vô hiệu hóa" (xóa) trình điều khiển Momentum Cache "không hoạt động", mà tôi đã thực hiện vào thứ Sáu, không có tác dụng. Dưới đây là dữ liệu trong ba ngày qua, cho thấy -- hãy xem cột màu đỏ, bạn có thể cần phải cuộn sang bên phải -- rằng WAF là 68,87 trong khoảng thời gian 24 giờ gần đây nhất

Nhấn để mở rộng...

:

Ngày	Tổng số lần ghi vào máy chủ (GB)	S.M.A.R.T. F7	S.M.A.R.T. F8	WAF = 1 + F8/F7	Tổng số lần ghi được khuếch đại (GB)	ΔF7 (1 hàng)	ΔF8 (1 hàng)	WAF gần đây = 1 + ΔF8/ΔF7	ΔF7 (2 hàng)	ΔF8 (2 hàng)	WAF gần đây (2 hàng) = 1 + ΔF8/ΔF7
02/06/2020

	6.323	219.805.860	1.229.734.020	6,59	41.698
02/07/2020	6.329	220.037.004	1.242.628.588	6,65	42.071	231.144	12.894.568	56,79
02/08/2020	6.334	220.297.938	1.252.694.764	6,69	42.351	260.934	10.066.176	39,58	492.078	22.960.744	47,66
02/09/2020	6.342	220.530.596	1.268.485.627	6,75	42.821	232.658	15.790.863	68,87	493.592	25.857.039	53,39

Một email ngày hôm qua từ bộ phận hỗ trợ kỹ thuật của Micron không đưa ra lời khuyên hữu ích nào: "Đối với sự cố bộ nhớ đệm động lượng, vì bạn đã thực hiện tất cả các bước khắc phục sự cố, tôi khuyên bạn nên thử gỡ cài đặt bộ điều hành Crucial Storage rồi cài đặt lại. Sự cố có thể nằm ở quản lý nguồn điện trên hệ thống của bạn hoặc ở Storage executive. Đối với % giảm, có thể là do đọc và ghi liên tục từ SSD. Tuy nhiên, đối với cả hai vấn đề nếu vẫn tiếp diễn, bạn có thể bỏ qua việc sử dụng Crucial storage executive và sử dụng bất kỳ phần mềm 'giám sát và kiểm soát' SSD của bên thứ 3 nào khác cho bộ nhớ đệm động lượng."

Lời khuyên của họ không hữu ích vì:
(1) Tôi đã thử gỡ cài đặt/cài đặt lại Storage Executive nhiều tuần trước (lần đầu tiên họ gợi ý).
(2) Có vẻ vô lý khi cho rằng % Tuổi thọ còn lại giảm nhanh có thể là do "đọc và ghi liên tục" vì ổ SSD của tôi được ghi ít hơn nhiều so với hầu hết mọi người ghi vào ổ SSD của họ. HWiNFO cho thấy Tốc độ ghi trung bình thấp hơn 0,1 MByte/giây trong nhiều tuần (chỉ tổng cộng 19 GB trong ba ngày qua, theo mức tăng của Tổng số lần ghi trên máy chủ từ 6.323 GB vào ngày 6 tháng 2 lên 6.342 GB vào ngày 9 tháng 2) và đôi khi cho thấy Tốc độ ghi hiện tại là 0. Tốc độ đọc trung bình là khoảng 0,22 MByte/giây và Tốc độ hiện tại Tốc độ đọc đôi khi là 0.
(3) Họ không chỉ rõ phần mềm 'giám sát và điều khiển' SSD của bên thứ ba nào có thể tương thích với MX500.

Để tham khảo, bo mạch chủ là MSI X470 Gaming Plus, CPU là Ryzen 3 3200G và hệ thống có 16GB (2 x 8GB) Corsair Vengeance 3200 dram (giảm xung nhịp ở mức 2400 nên sẽ chạy ở mức 1,2V). Không cài đặt card đồ họa vì CPU là APU.

Có lẽ trình điều khiển của bên thứ ba đang gây ra sự cố? VMware Player đã được cài đặt từ mùa hè năm ngoái và mặc dù tôi hiếm khi chạy máy ảo nữa, nhưng VMware Player đã tự cài đặt một số bản cập nhật. Có lẽ trình điều khiển đĩa ảo bị lỗi có thể can thiệp vào ổ SSD ngay cả khi Player không chạy máy ảo?

Phần mềm giám sát dữ liệu S.M.A.R.T. có thể can thiệp vào ổ SSD không? Một lúc trước, tôi đã thoát khỏi HWiNFO và CrystalDiskInfo, những chương trình thường chạy 24 giờ mỗi ngày. Trong một hoặc hai ngày nữa, tôi có thể kiểm tra WAF gần đây để xem nó có bị ảnh hưởng do không chạy chúng không.

Liệu chương trình cơ sở ssd có bị lỗi khi ghi trên máy chủ ít hơn nhiều so với thông thường không? Có thể đây là trường hợp sử dụng mà Crucial/Micron chưa từng thử nghiệm. Khoảng hai tháng trước, khi Tuổi thọ còn lại đạt 95%, tôi đã thực hiện các bước để giảm đáng kể việc ghi trên máy chủ (di chuyển hồ sơ Firefox sang ổ cứng, thiết lập simlink để CyberPower UPS ghi nhật ký vào ổ cứng thay vì ổ SSD, tắt chức năng quét phần mềm diệt vi-rút của Comodo trong các tệp nén, v.v.) nhưng tốc độ giảm Tuổi thọ còn lại đã tăng tốc kể từ đó. Trong khoảng 7 tháng sử dụng ổ SSD, WAF của nó trung bình là 6,75 (giá trị ngày 9 tháng 2 trong bảng trên), thấp hơn một bậc độ lớn so với giá trị WAF của những ngày gần đây. Tuy nhiên, đây có thể là sự trùng hợp ngẫu nhiên vì Windows, trình điều khiển MSI và các phần mềm khác đã nhận được các bản cập nhật có thể là nguyên nhân.

Bạn có gợi ý nào về những gì tôi nên thử không?

Yêu cầu thay thế ổ SSD theo chế độ bảo hành có hợp lý không?

Nhấn để mở rộng...

@Maxxify, tWAF trung bình ~6 trong ~5 tháng đầu tiên của ổ đĩa có vẻ không liên quan. Vấn đề chính là WAF hiện ở mức khoảng 60, cao hơn một bậc độ lớn. Vì WAF hiện rất lớn, nên không dễ chịu gì khi ổ SSD có thể tồn tại hơn một thập kỷ nếu WAF của nó trung bình "chỉ" là 6,75 trong thập kỷ đó. Với Tốc độ ghi trung bình trên máy chủ nhỏ hiện tại (dưới 0,1 MByte/giây) và WAF lớn, ổ đĩa có thể chỉ vượt quá thời hạn bảo hành 5 năm, nhưng tôi không muốn bị buộc phải duy trì tốc độ ghi nhỏ hiện tại; đó sẽ là một hạn chế vô lý.

@Mr.Spock, tôi không hiểu làm sao việc ghi do tệp trang, tệp vm hoặc tệp Temp gây ra có thể giải thích được WAF lớn. Ngoài ra, tệp pagefile, vm và Temp đã được tính đến vì những lần ghi đó được bao gồm trong Ghi trung bình của máy chủ, rất nhỏ. Hơn nữa, tôi đã di chuyển tệp pagefile sang ổ cứng nhiều tháng trước. Tôi hầu như không bao giờ chạy vm... không một lần nào trong tháng qua. Comodo định kỳ ghi rất nhiều tệp tạm thời vào ổ ssd khi Quét toàn bộ hàng tuần của nó được đặt thành quét vi-rút các tệp nén, đó là lý do tại sao tôi quyết định tắt chức năng quét các tệp nén sau khi Tuổi thọ còn lại của ổ ssd đạt 95%. (Một giải pháp thay thế là tìm hiểu nơi Comodo ghi các tệp tạm thời đó và tạo liên kết tượng trưng từ đó đến một thư mục trên ổ cứng.)

Theo Storage Executive, chương trình cơ sở của ổ ssd đã được cập nhật (và đó là phiên bản giống như khi ổ còn mới, M3CR023). Tôi không biết cách kiểm tra xem phần mềm có "hỏng" không nhưng tôi cho rằng nó không hỏng nếu được cập nhật và bộ phận hỗ trợ kỹ thuật của Micron không nói rằng nó hỏng.

Theo BIOS, AHCI được bật.

Số lần xóa khối trung bình tăng lên 109 khi tôi viết bài đăng này. <thở dài>

109 / 3000 = ~3,63%, tương ứng với số TBW của bạn.

vậy nên RL 95-97% là đúng, một lần nữa bạn đang xem xét 6+ năm theo tỷ lệ hiện tại

@Mr.Spock: Tôi nghĩ bạn đang xác nhận có một vấn đề lớn, vì 6 năm trở lên là quá ngắn so với tốc độ ghi trung bình trên máy chủ chỉ 0,1 MByte/giây.
Không chắc bạn muốn nói gì khi nói "95-97% RL là đúng". RL là 93% và là 95% cách đây khoảng 6 tuần.

Đây là một bí ẩn khác mà tôi vừa nhận thấy: "Giờ bật nguồn" của S.M.A.R.T. là 968. Chỉ khoảng 40 ngày, mặc dù ổ SSD đã hoạt động từ mùa hè năm ngoái và máy tính đã bật và được đặt ở chế độ Không bao giờ ngủ trong gần như toàn bộ 5 tháng qua. Sau đây là một đoạn trích về Giờ bật nguồn từ S.M.A.R.T. của Micron. Tài liệu thuộc tính:
Giá trị này cung cấp số giờ thô mà ổ đĩa
đã được cấp nguồn (trực tuyến) trong suốt vòng đời của nó.
Thuộc tính này sẽ tăng lên theo từng giờ trong
trạng thái nguồn liên kết sau:
• SATA PHYRDY (Liên kết đang hoạt động)
Thuộc tính này không được tăng lên theo từng giờ trong
trạng thái nguồn liên kết sau:
• SATA một phần
• SATA ngủ
• SATA thiết bị ngủ

Có thực sự có khả năng ổ SSD đã dành phần lớn thời gian ở trạng thái Một phần hoặc Ngủ hoặc Thiết bị ngủ không, vì máy tính đã bật và Không bao giờ ngủ và cài đặt chế độ nguồn là "Tắt ổ cứng sau" là 0 phút?

Trong trường hợp ổ SSD bị hỏng do máy tính được bật trong nhiều tuần mà không tắt máy, tôi đã tắt tạm thời nó đã bị sập một lúc trước. Trước khi tắt máy, tôi đã thiết lập HWiNFO và CrystalDiskInfo để chúng không khởi động cùng Windows và tôi sẽ không chạy chúng trong vài ngày, trong trường hợp việc giám sát của chúng bằng cách nào đó can thiệp vào ổ SSD. Tôi sẽ tiếp tục theo dõi WAF mỗi ngày để xem liệu bất kỳ bước nào trong số đó có giúp ích không.

Vào một thời điểm nào đó, tôi có thể tăng tốc độ ghi để xem liệu điều đó có ảnh hưởng đến WAF hay không. Ví dụ, tôi có thể chuyển hồ sơ Firefox trở lại ổ SSD.

Tại sao bạn không liên hệ với Crucial và xem họ nói gì.
Đặc biệt là khi xét đến thời gian bật nguồn thấp một cách đáng ngờ.

Tôi không hiểu tại sao công thức cho WAF lại không phải là …

WAF = F8 /F7

… mà là …

WAF = (F8 + F7) / F7 = 1 + F8/F7

Giá trị WAF sau không bao giờ có thể nhỏ hơn 1, ngay cả khi nén.

Giả sử bạn muốn nói đến thiết lập kế hoạch nguồn điện là Tắt ổ cứng sau = "Không bao giờ"?
vâng, điều đó có nghĩa là bộ điều khiển SATA đang ở chế độ ngủ định kỳ trái ngược với ổ đĩa.

Một lần nữa, tối thiểu 6 năm là chỉ báo ngay bây giờ cho các chu kỳ TBW và P/E. Bạn cũng có 4 năm để RMA nếu bạn cảm thấy nó bị lỗi - nhưng số liệu thống kê không có vẻ đáng báo động ngay bây giờ.