در این مقاله به بررسی مزایا و معایب کنترلر SSD در «فعال و غیرفعال کردن کش داده» می‌پردازیم و به نحوه‌ی کارکرد و حوزه‌ی کاربرد آن‌ها نگاهی می‌کنیم. لطفا توجه کنید که در اینجا منظور از «حافظه کش»، بافر کردن قبل از نوشتن در فلش NAND است و به «نرخ موفقیت در خواندن» (read hit rate- تعداد دفعاتی که داده مورد نظر در کش وجود دارد) ارتباطی ندارد.

همانطور که در شکل 1 نشان داده شده، یک کنترلر SSD از سه بخش تشکیل شده است: front، بافر و back. به طور کلی، قسمت جلو (front) برای ارتباط با هاست و شرکت در فرایند بعضی از دستورات استاندارد طراحی شده است. قسمت بافر با هدف بافر کردن داده‌های خواندن یا نوشتن در بافر DRAM یا SRAM  ساخته شده و در عین حال، قسمت پشت (back) به دستورات فلش رسیدگی می‌کند و خطاهای بیت داده را با موتور ECC تصحیح می‌کند.

یک کارکرد معمول که توسط کنترلر فعلی SSD انجام می‌شود، ذخیره‌ی داده‌ها از هاست در بافر داده، در مرحله‌ی اول و سپس نوشتن آن‌ها در فلش NAND با موتور سخت‌افزاری DMA (Direct memory access- دسترسی مستقیم به حافظه) است که توسط فریمور فراهم می‌شود و تا زمانی ادامه دارد که حجم مشخصی از بافر پر شود. به این حالت، «حالت کش داده» (Data cache mode) گفته می‌شود که از مزایای زیر برخوردار است:

1. ترکیب در یک صفحه‌ی برنامه: فلش NAND اجازه‌ی پروگرم کردن یک صفحه را در یک زمان می‌دهد. اندازه‌ی صفحه که معمولا مورد استفاده قرار می‌گیرد، 16 کیلوبایت است. برای یک دستور نوشتن با داده‌ی 4 کیلوبایتی، به‌صرفه‌تر است که 4 «قطعه» (chunk) از داده‌ی 4 کیلوبایتی، در حافظه کش داده، بافر شود تا پس از آن در NAND نوشته شود.
2. هنگامی که داده‌ی نوشتن، شامل LBAS یکسان است، داده را مستقیما در همان LBA (آدرس منطقی بلوک-Logical Block Address : برای ثبت داده‌های LBAها) می‌نویسد تا نرخ WAI (Write Amplification- محدوده‌ی نوشتن) از SSD را کاهش دهد. این مورد، مخصوصا برای کش DRAM بسیار مفید است.

حالت کش داده (Data cache mode) در زمان قطع شدن برق، با مشکلی جدی مواجه است. هنگامی که برق می‌رود، ممکن است داده‌های بافر شده در حافظه کش داده که احتمالا SRAM یا DRAM است، از بین بروند یا آسیبی جدی ببینند. این مسأله باید برای برنامه‌هایی که نمی‌توانند ریسک از دست رفتن اطلاعات را بپذیرند، مورد توجه قرار گیرد.

یکی از راه‌های حل این مشکل، اضافه کردن یک ابَرخازن (super CAP) در SSD است تا برق کافی را برای داده‌های موجود در حافظه کش داده فراهم کند تا در صورت قطع برق، فلش NAND آپدیت شود. کاملا بدیهی است که این امر، هزینه‌های بیشتری را می‌طلبد. هرچه حافظه کش بزرگ‌تر باشد، به خازنی با ظرفیت بیشتری نیاز دارد تا زمان بیشتری برای به‌روزرسانی داده‌ها داشته باشد.

راه‌حل دیگر «حالت بدون کش» (Non-cache mode) است. همانطور که در شکل بالا مشخص است، داده‌ها مستقیما روی فلش NAND نوشته شده‌اند، بدون اینکه بافری در میان باشد. کنترلر فقط هنگامی که دستور نوشتن فلش NAND آماده باشد، پیام «دستور آماده است» (command ready) را به هاست می‌فرستد. این روش هزینه‌ها را افزایش نمی‌دهد و فقط به تغییراتی در PCBها نیاز دارد و دیگر به هیچ ابرخازنی احتیاجی نیست. معایب آن هم واضح است: از آن‌جایی که هر دستور، فقط پس از پایان عملیات نوشتن داده‌ی NAND می‌تواند به هاست پاسخ دهد، این روش بهره‌وری بالایی ندارد. از سوی دیگر، وقتی که عمل نوشتن هاست، کوچک‌تر از حداقل واحد نوشتن NAND است، مجبور است برخی الگوهای ساختگی را استفاده کند تا نرخ WAI مربوط به SSD را بالا ببرد و در این صورت، حجم کل داده‌هایی را که می‌توان در SSD نوشت، کاهش می‌دهد.

همانطور که در بالا توضیح دادیم، هریک از این سه رویکرد، جنبه‌هایی مثبت و منفی دارند. در برخی از برنامه‌های کنترل شبه‌صنعتی (به عنوان مثال POS)، هرگونه خاموشی غیرطبیعی است؛ زیرا هاست هیچ فرایند طبیعی‌ای برای قطع شدن برق ندارد، با این حال باید همچنان با از دست رفتن داده‌ها مقابله و از آن جلوگیری کرد. با این حال، برنامه‌هایی این‌چنینی، به نوشتن داده‌های کمی نیاز دارند و به عملکرد و حجم کلی نوشتن نیز کمتر وابسته هستند. در اینجا احتمالا حالت بدون کش، گزینه‌ی مناسبی خواهد بود.