پروژههایی که از ظرفیت لپتاپم فراتر میروند، راهی یک SSD اکسترنال میشوند. با این حال، تصورم این بود که ویندوز از درایوهای خارجی و داخلی به یک شیوه نگهداری میکند. در ظاهر همهچیز عادی بود، اما وقتی به قاب SSD توجه کردم، به مشکلی برخوردم. ممکن است یک SSD در یک قاب، قابلیت ReTrim را در دسترس نشان دهد، اما همان درایو در قابی دیگر اعلام کند که هیچ عملیاتی در دسترس نیست.
برای این آزمایش، همان SSD را در دو قاب معمولی و بینامونشان به کار گرفتم.
fsutil در ظاهر سلامت درایوم را تأیید کرد، اما یک قید مهم در عبارت آن بود۰ به معنای «تأیید شده» نیست؛ یعنی «صریحاً رد نشده است»
در ترمینال، این فرمان را اجرا کردم:
fsutil behavior query DisableDeleteNotifyنتیجه ۰ بود. هرچند روی کاغذ شاید نشانهای مثبت به نظر برسد، در عمل با یک منفیِ دوگانه روبهرو هستیم. این فقط میگوید ویندوز اعلانهای TRIM/حذف را مسدود نمیکند؛ اما هیچ نمیگوید که SSD این اعلانها را دریافت میکند یا اصلاً درایو بر پایه آنها کاری انجام میدهد.
سپس «بهینهسازی درایوها» را بررسی کردم و در پاورشل، فرمان Optimize-Volume -ReTrim را اجرا کردم. در هر دو حالت، ویندوز درایو اکسترنال را بهعنوان رسانهٔ حالتجامد تشخیص داد و مسیرهای بهینهسازی مورد انتظار برای هر SSD را در اختیار گذاشت. این بررسیها نشان میداد ویندوز حاضر است چه کاری انجام دهد، اما تأیید نمیکرد که تراشه پلِ قاب، فرمان UNMAP را دور میریزد یا آن را به SSD میرساند.
وقتی همین ابزارها را برای یک درایو داخلی NVMe به کار میبرید، تصویر کاملتری به دست میآورید. پس از اجرای ReTrim، گزارش رویدادها معمولاً مدخلی روشن از سابقه بهینهسازی نشان میدهند؛ راهی برای تأیید اینکه فرمان کامل شده است. سابقه ولوم اکسترنال من فقط نشان میداد که رسانهای حالتجامد با زمانبندی فعال دارم.
از سمت ویندوز همهچیز درست به نظر میرسید و هیچ نشانهای از شکست فرایند نگهداری وجود نداشت. اما پرسش اصلی این بود که آیا میان درگاه USB و NAND، مسیر کاملی وجود دارد یا نه.
SSD من هرگز مستقیم با ویندوز حرف نمیزد؛ این قاب بود که سخن میگفت
تراشههای پل USB فرمانهای ذخیرهسازی را ترجمه میکنند و همین ترجمه محل گمشدن فرمانهاست
وقتی مسیر را ترسیم کنید، روند ساده است: پشته ذخیرهسازی USB فرمان UNMAP در سطح SCSI را از ویندوز دریافت میکند. این همان فرمانی است که پشت رفتار TRIM قابلمشاهده برای کاربر در ویندوز قرار دارد. سپس پلِ قاب باید آن را به زبانی ترجمه کند که کنترلر SSD میفهمد؛ پس از آن، کنترلر میتواند آن بلوک را آزاد علامتگذاری کند.
اشتباه این است که قاب را یک لوله شفاف فرض کنیم. پلها مترجماند و ممکن است هنگام ترجمه، فرمانهای مشخص SCSI مانند UNMAP را کنار بگذارند. UASP به شما میگوید قاب از پروتکل USB Attached SCSI استفاده میکند، اما تضمین نمیکند که همه فرمانهای ذخیرهسازی، از جمله UNMAP، تا انتهای مسیر عبور کنند. بنابراین ممکن است یک قاب نتواند TRIM/UNMAP را منتقل کند، حتی اگر USB ۳.۲ را تبلیغ کند. در برخی مدلها، ترجمه فقط در شرایطی مشخص درست پیادهسازی میشود؛ شرایطی که ممکن است شامل یک کنترلر USB معین، نسخههای مشخص میانافزار یا اتصال سرد باشد؛ یعنی دستگاه را هنگامی وصل کنید که میزبان خاموش است. در همه سناریوهای دیگر، عملکردشان از کار میافتد.
مسیر چنین است: ویندوز ← پشته USB ← تراشه پل ← کنترلر SSD ← NAND. درایوها معمولاً از TRIM پشتیبانی میکنند، اما این قاب است که تعیین میکند میزبان بتواند این پشتیبانی را ببیند یا نه. ازاینرو، میان پشتیبانی یک SSD از TRIM و پشتیبانی آن از TRIM از راه یک قاب مشخص، تفاوتی روشن وجود دارد. اشتباه این است که این دو را یکسان بدانیم.
تعویض قاب، پاسخ ویندوز را تغییر داد؛ نه خود SSD را
یک درایو، یک رایانه، دو تراشه پل و دو نتیجه متفاوت
قاب SSD را عوض کردم. هر دو مدل معمولی بودند و هیچکدام ویژگی خاصی نداشتند. بهجز پوسته پلاستیکی و پل آن، همه اجزای دیگر ــ درایو، درگاه USB و کابل ــ یکسان ماندند. این دو قاب ماهها بهطور منظم استفاده شده بودند و بارهای کاری مشابهی را پردازش میکردند؛ از بایگانی عکس و فایلهای ویدئویی و موسیقی گرفته تا پوشههای بزرگ پروژه.
ویندوز هر دو را بهصورت درایوهای حالتجامد متصلشده از راه USB نشان داد. بخش «بهینهسازی درایوها» نوع رسانه را «درایو حالتجامد» فهرست میکرد، اما وقتی درخواست ReTrim دادم، تفاوت آشکار شد: در یک قاب، عملیات در دسترس بود؛ اما در دیگری، عملیاتی در دسترس نبود.
| قاب A | قاب B | |
|---|---|---|
| همان SSD | ✓ | ✓ |
| ویندوز SSD را شناسایی میکند | ✓ | ✓ |
| نوع درایو در «بهینهسازی درایوها» | درایو حالتجامد | درایو حالتجامد |
| بهینهسازی ویندوز | ReTrim در دسترس است | بدون عملیات |
از حدسزدن درباره خانوادههای تراشه پرهیز کردم و خودِ قاب را متغیر آزمایش در نظر گرفتم، چون نتوانستم کنترلرهای پلِ هرکدام را با اطمینان شناسایی کنم. حتی وقتی دستگاهها یکسان به نظر میرسند، میانافزار و جزئیات پیادهسازیشان ممکن است تفاوت داشته باشد. بنابراین، وقتی SSD و رایانه ثابت ماندهاند، بعید است نتایج صرفاً تصادفی باشند.
قابهایی که TRIM را پشتیبانی نمیکنند، عملکرد نوشتن را فوراً از پا نمیاندازند. با این حال، کنترلر اطلاعات کمتری درباره بلوکهایی دریافت میکند که دیگر نیازی به آنها نیست؛ در نتیجه، فرصتهایش برای آمادهسازی کارآمد فضای خالی کمتر میشود. بسته به SSD، نوع بار کاری و قاب، این موضوع میتواند به عاملی مهم تبدیل شود.
هر قابی سزاوار SSD شما نیست
پیش از آنکه سراغ عیبیابی مشکلات عملکرد بروید یا یک SSD خارجی بخرید، این سه پرسش را مطرح کنید:
- آیا قاب صراحتاً از TRIM/UNMAP پشتیبانی میکند، یا فقط سرعتهای USB ۳.۲ را تبلیغ میکند؟
- آیا سازنده بهروزرسانی میانافزار ارائه میدهد؟
- آیا بررسیها یا کالبدشکافیهای مستقل، تراشه پل را شناسایی کرده و به رفتار TRIM/UNMAP اشاره میکنند؟
بسیاری از پاسخهای موردنیازتان را باید در انجمنهای تخصصی ذخیرهسازی پیدا کنید و متأسفانه لزوماً در صفحههای فروش نیستند. شماری از قابهای ارزانقیمت شاید این فرمان را بهطور قابلاعتماد عبور ندهند، اما بعضی ایستگاههای اتصال و قابهای ردهبالاتر چنین میکنند. با این همه، تفاوتشان معمولاً از ظاهر دستگاه آشکار نیست.
منبع: این مطلب ترجمه و بومیسازی مقالهای از MakeUseOf به قلم Afam Onyimadu است. مشاهده مقاله اصلی