Death Of WinFS?

I wrote about WinFS late last year and provided some of my thoughts on the subject. In the days and weeks after writing the post, I noticed a massive number of referrers in my logs from microsoft.com directly to that post. For a period of weeks, it was my most viewed post — mostly from employees at Microsoft. Apparently, it touched a nerve and people must have received it in widely sent internal emails.

Microsoft announced recently that they’re essentially slowing the growth of the project by including it as a component of SQL Server. I have never fully liked the idea of an object-relational file system —- especially if it comes from Microsoft. That’s not because I enjoy Microsoft bashing, but I have real-world experience with storing massive numbers of files in Windows file systems.  NTFS just doesn’t cut it when you exceed 25 million files per partition. If a machine sets the dirty bit on that partition, a reboot can take days potentially to complete due to checkdsk. Adding layers to the file system to add nifty functionality is great in theory, but in practice it’s almost impossible to make it scale for enterprises when it’s based on a Windows file system.

WinFS sounded better for the consumer in some regards. They’ll never need the same sort of scalability that enterprise data centers demand, but the adoption of such functionality is still dependent on application developers seeing value in the offering.  Bundling WinFS with SQL Server is one assured way of keeping it out of the consumer space unless perhaps an application uses the developer edition of SQL Server.  But this is still a big barrier if Microsoft wanted to see adoption in the consumer space.

I spent the better part of the last decade dealing with issues surrounding adding metadata to NTFS using something called the extended attribute block. It’s sort of a free form area of the file system for low-level developers to store stuff. It was a bad idea to use the EA block to store meta information and I doubt that WinFS was much better.