بله، بعضی SSDها با پر شدن کند می‌شوند؛ اما نه به این معنی که هر SSD پس از عبور از یک درصد مشخص ناگهان افت سرعت پیدا می‌کند. اثر واقعی به معماری کنترلر، نوع NAND، اندازه و نوع کش، مقدار Over-Provisioning، وضعیت TRIM و نوع بار کاری وابسته است. معمولاً افت عملکرد ابتدا در نوشتن‌های طولانی، انتقال فایل‌های بزرگ، پروژه‌های تدوین و کار با Scratch Disk دیده می‌شود؛ نه لزوماً در خواندن ساده فایل‌ها.
قانون «همیشه ۲۰ درصد SSD را خالی نگه دارید» یک توصیه محافظه‌کارانه است، نه یک عدد فنی ثابت برای همه درایوها.
| نوع استفاده | فضای خالی عملی پیشنهادی | دلیل |
|---|---|---|
| استفاده روزمره و اداری | حدود ۱۰ تا ۱۵ درصد | حاشیه مناسب برای ویندوز، به‌روزرسانی‌ها و کار کنترلر |
| تدوین، افترافکت، کش، Scratch و نوشتن سنگین | حدود ۱۵ تا ۲۵ درصد | کاهش احتمال افت نوشتن پایدار و کمبود فضای کاری پروژه |
| آرشیو و بار عمدتاً خواندنی | کمتر از این مقدار هم ممکن است کافی باشد | نوشتن و بازنویسی محدود است |
| درایو سیستم‌عامل | فقط درصد کافی نیست؛ چند ده گیگابایت فضای واقعی نیز لازم است | آپدیت، Pagefile، Temp و Restore Point به فضای مطلق نیاز دارند |
این اعداد «حد خرابی» نیستند. ممکن است یک SSD خوب در ۹۰ درصد ظرفیت همچنان عملکرد قابل قبولی داشته باشد و مدل دیگری در همان وضعیت، هنگام نوشتن طولانی افت محسوسی نشان دهد. معیار درست، رفتار همان مدل SSD در بار واقعی شماست.
حافظه NAND در سطح Page نوشته می‌شود، اما پاک‌کردن اطلاعات در سطح بزرگ‌تری به نام Block انجام می‌شود. کنترلر نمی‌تواند یک Page استفاده‌شده را مانند RAM مستقیماً روی همان محل بازنویسی کند. هنگام تغییر یک فایل، داده جدید معمولاً در محل دیگری نوشته و نسخه قبلی نامعتبر علامت‌گذاری می‌شود.
بعداً کنترلر باید Pageهای معتبر یک Block را جابه‌جا کند، Block را پاک کند و دوباره فضای قابل‌نوشتن بسازد. این فرایند بخشی از Garbage Collection است. هرچه فضای قابل‌استفاده و Blockهای آماده کمتر شوند، کنترلر ممکن است برای نوشتن مقدار کمی داده، عملیات داخلی بیشتری انجام دهد. نتیجه می‌تواند افزایش Write Amplification، افت نوشتن پایدار و نوسان بیشتر زمان پاسخ باشد.
وقتی فایلی را در سیستم‌عامل حذف می‌کنید، SSD لزوماً از همان لحظه نمی‌داند داده‌های مربوط به آن دیگر لازم نیستند. فرمان TRIM یا Dataset Management به درایو اعلام می‌کند کدام آدرس‌های منطقی دیگر داده معتبر ندارند. کنترلر می‌تواند از این اطلاعات برای مدیریت بهتر Garbage Collection استفاده کند.
TRIM به معنی پاک‌شدن فوری تمام سلول‌ها نیست. زمان و روش پاک‌سازی را Firmware و کنترلر تعیین می‌کنند. به همین دلیل ممکن است پس از حذف یک فایل حجیم، سرعت نوشتن بلافاصله به بهترین حالت برنگردد؛ مخصوصاً اگر درایو زیر بار باشد، کش تخلیه نشده باشد یا Garbage Collection هنوز فرصت کافی پیدا نکرده باشد.
fsutil behavior query DisableDeleteNotifyنام این گزینه گمراه‌کننده است: مقدار 0 یعنی ارسال اعلان حذف یا TRIM فعال است؛ مقدار 1 یعنی غیرفعال است. در نصب‌های معمول ویندوز و SSDهای امروزی، TRIM عموماً به‌صورت پیش‌فرض فعال است و تغییر دستی آن بدون تشخیص دلیل موجه نیست.
برای درخواست ReTrim در ویندوز می‌توان از ابزار Optimize Drives یا دستور مدیریتی زیر استفاده کرد:
Optimize-Volume -DriveLetter C -ReTrim -Verboseاجرای وسواس‌گونه این دستور مزیت اثبات‌شده‌ای ندارد. همچنین Defrag دستی و تکراری را نباید به‌عنوان درمان عمومی کندی SSD اجرا کرد. بخش Optimize ویندوز نوع رسانه را تشخیص می‌دهد و برای SSD معمولاً عملیات مناسب مانند ReTrim را مدیریت می‌کند.
بسیاری از SSDهای مصرفی TLC و QLC برای بالا بردن سرعت نوشتن کوتاه‌مدت، بخشی از NAND را در حالت شبهSLC یا pSLC Cache به‌کار می‌گیرند. فایل ابتدا با سرعت بالا وارد این کش می‌شود و بعد کنترلر آن را به ساختار اصلی TLC یا QLC منتقل می‌کند.
به همین دلیل سرعت درج‌شده روی جعبه معمولاً سرعت Burst در شرایط مشخص است، نه تضمین سرعت نوشتن تا انتهای ظرفیت. پس از پر شدن کش، سرعت ممکن است به سرعت واقعی NAND کاهش پیدا کند. شدت افت در مدل‌های مختلف بسیار متفاوت است و صرف عبارت TLC یا QLC برای پیش‌بینی دقیق کافی نیست.
برای انتخاب درایو مناسب پروژه‌های رسانه‌ای، مقاله بهترین SSD برای تدوین؛ بررسی سرعت پایدار، کش و ظرفیت معیارهای مهم‌تری از عدد تبلیغاتی Sequential Speed را توضیح می‌دهد.
Over-Provisioning بخشی از ظرفیت NAND است که در اختیار مستقیم کاربر قرار نمی‌گیرد یا به‌صورت فضای تخصیص‌نیافته برای کار کنترلر رزرو می‌شود. کنترلر از این حاشیه برای جایگزینی سلول‌ها، Wear Leveling، Garbage Collection و حفظ ثبات عملکرد استفاده می‌کند.
فضای خالی داخل فایل‌سیستم دقیقاً همان Over-Provisioning نیست. بااین‌حال وقتی TRIM فعال باشد، کنترلر می‌تواند بداند کدام محدوده‌های آزاد دیگر داده معتبر ندارند و از آن‌ها در مدیریت داخلی استفاده کند. ایجاد فضای Unallocated اختصاصی در بعضی سناریوهای نوشتن سنگین مفید است، اما برای همه کاربران ضروری نیست و جای انتخاب SSD مناسب را نمی‌گیرد.
اثر مستقیم پر شدن معمولاً در نوشتن پررنگ‌تر است. خواندن داده موجود نیازمند پاک‌کردن Block یا ساخت فضای جدید نیست. بااین‌حال یک سیستم تقریباً بدون فضای خالی ممکن است از مسیرهای دیگری کند شود: ویندوز برای فایل‌های موقت، به‌روزرسانی، Pagefile و کش برنامه‌ها فضای کافی ندارد؛ نرم‌افزار تدوین یا مرورگر نمی‌تواند کش بسازد؛ و عملیات پس‌زمینه درایو هم‌زمان با بار کاربر انجام می‌شود.
بنابراین «SSD پر است و سیستم کند شده» لزوماً به معنی افت سرعت خام خواندن NAND نیست. باید میان عملکرد خود درایو و فشار فضای آزاد روی سیستم‌عامل و نرم‌افزارها تفکیک کرد.
در بازی‌ها نیز عدد بالای سرعت ترتیبی به‌تنهایی تعیین‌کننده نیست. مقاله تأثیر سرعت SSD در رندر Real-Time و DirectStorage تفاوت میان پهنای‌باند، زمان بارگذاری و گلوگاه واقعی را بررسی می‌کند.
اجرای پی‌درپی بنچمارک‌های نوشتن سنگین برای «بهبود» SSD روش مناسبی نیست؛ این تست‌ها خودشان داده زیادی می‌نویسند و می‌توانند کش و وضعیت حرارتی را تغییر دهند. هدف باید تشخیص الگوی افت باشد، نه گرفتن بالاترین عدد ممکن.
در سیستم‌های حرفه‌ای بهتر است ظرفیت فقط بر اساس اندازه فعلی پروژه انتخاب نشود. فایل‌های موقت، Media Cache، Proxy، Preview، Auto Save و خروجی‌های میانی می‌توانند فضای زیادی مصرف کنند. درایوی که از روز اول نزدیک به ظرفیت کار می‌کند، انتخاب اقتصادی دقیقی نیست؛ حتی اگر در تست کوتاه سرعت بالایی نشان دهد.
پر شدن SSD می‌تواند به‌ویژه در نوشتن‌های طولانی باعث افت سرعت شود، چون فضای کاری کنترلر، ظرفیت کش پویا و امکان اجرای مؤثر Garbage Collection محدودتر می‌شود. اما یک درصد ثابت برای همه درایوها وجود ندارد. برای استفاده روزمره، حدود ۱۰ تا ۱۵ درصد فضای خالی معمولاً حاشیه عملی مناسبی است؛ در تدوین و بارهای نوشتن سنگین، ۱۵ تا ۲۵ درصد محافظه‌کارانه‌تر است.
اگر SSD با فضای کافی همچنان کند است، قبل از تعویض آن باید دما، اندازه کش، رابط PCIe، Firmware، پردازش‌های پس‌زمینه، RAM و سلامت درایو بررسی شوند. «پر بودن» فقط یکی از علت‌های ممکن است.
خیر. این عدد توصیه‌ای محافظه‌کارانه است. نوع SSD، کش، Over-Provisioning و بار کاری تعیین می‌کنند چه مقدار حاشیه لازم است.
معمولاً اثر مستقیم روی نوشتن بیشتر است. کندی خواندن یا کل سیستم می‌تواند ناشی از کمبود فضای فایل‌های موقت، دما، بار پس‌زمینه یا مشکلات دیگر باشد.
نه همیشه. TRIM باید فضای آزاد را اعلام کند و کنترلر نیز ممکن است برای Garbage Collection و تخلیه کش به زمان بیکاری نیاز داشته باشد.
خیر. TRIM به کنترلر کمک می‌کند داده‌های غیرلازم را بشناسد و مدیریت نوشتن را مؤثرتر انجام دهد. غیرفعال‌کردن آن بدون دلیل توصیه نمی‌شود.
تست کوتاه ممکن است داخل SLC Cache انجام شود. در کپی طولانی، کش پر می‌شود و سرعت واقعی NAND، دما و مدیریت داخلی درایو تعیین‌کننده می‌شوند.
