Saturday, July 23, 2005

Running Vista on Flash

Korean vendors are releasing large and fast flash chips and prospect to introduce units up to 100GB in the foreseeable future. Speculations float around on notebooks running on these flash devices in place of hard disks. Many are concerned about the performance and writing cycles of these units once used in full-fledged Windows Vista instead of Windows CE. I'm thinking it's well time to revise NTFS for this trend. An FS running on solid state should be designed with these in mind:
  • Caching
  • Shuffling
  • Striping
  • No defragging at all
Caching is nothing new as all modern systems have been designed with it. We may just balance the depth of caching and data integrity in case of crash/power failure. I especially like the mechanism in RAID controllers. They have tons of memory on board with a little battery. During a crash or power failure, the battery holds the cache in place and the onboard firmware flushes the cache during next initialization. We may do something like this, either software based for the whole FS, or hardware based for at lease the most write-intensive portion (MFT, etc., maybe). Shuffling is critical to prevent flash to be worn out unevenly too fast. A simple implementation I can think of is making all the free space blocks a sequential queue. When even any block is being over-written, instead of just over-writing it, first release it into the free blocks queue, and request another block from the queue. This could shuffle the writing efficiently. And, the queue itself along with other fundamental FS structures need shuffling too. Maybe we might just use the same approach when updating the FS structure itself. We might end up in a roaming and crawling MFT as well. Speaking of striping across multiple chip banks, I doubt flash unit manufactures are doing that already in high-speed cards. Anyway, it’s very easy to implement either in hardware or driver level. Defragging is no longer needed. Flash devices are true random access memory compared to disks as sequential-random hybrid. Anything in FS design to reduce fragments in the trade off of complexity, (computational) intensity, and most importantly unevenly worn out can be disable. The resulting FS maybe an NTFS variation, or a driver/filter beneath it. And it may write blocks in a fashion that resemble a transactional database.

No comments: