Microsoft storage: a litany of failure

The result is a spectacular revolt in the user community, and a demand that Microsoft actually considers the home server user as a real customer.

How this will be resolved is anyone’s guess. Microsoft says we should be using RAID controllers instead.

The vendor Drobo has spotted a market opportunity and is offering discounts on its range of well-regarded external intelligent drive arrays, which coincidentally provide just such a drive-extending and dual copy facility.

Isn’t it strange how it’s possible for Drobo to offer this functionality but beyond the geniuses at Microsoft (it’s exactly the same story with Dropbox, which is eating Microsoft’s Live Mesh for lunch)?

Isn’t it strange how it’s possible for Drobo to offer this functionality but beyond the geniuses at Microsoft?

Of course both Drobo and Dropbox just do what they do, and nothing else, which means they’re highly focused on getting it right as otherwise their business dies.

Microsoft always has the luxury of walking away from difficult problems, although it would be nice if it didn’t try to spin that as something else.

Storage history

The reality is that Microsoft has no overarching strategy for storage. End of discussion. I know this will go down badly with the people at Redmond, but history shows this to be a fact.

Let’s go back to the days of MS-DOS and Windows 3.x. Remember DriveSpace, which Microsoft implemented in response to Stac’s Stacker?

It was a horrible thing, a piece of dodgy technology that empowered you to lose everything in one go. For Windows NT, Microsoft’s crack team of software engineers imported from Digital came up with the NTFS file system, which has provided the bedrock for Microsoft’s storage for almost 20 years.

That’s been a paragon of stability and capability, but it’s now 20-year-old thinking. Yes, it allows for mount points and so forth in a way to get around the hegemony of drive letters, but very few people use this feature.

Next up in the Hall of Shame was the Cairo Object File System. Designed to be an active store into which you could drop data, this never saw the light of day.

In fact, I saw it for real only once, and it died along with the whole Cairo project. The next tragedy was drive M in Exchange Server, which allowed you to mount the Exchange Server public folders as a drive letter, M being the default one.

This seemed a great idea at the time: to have file system access into the Exchange Server replicating store, and let Exchange Server do all the heavy work.

The problem was that it was terrifyingly fragile, so almost anything you did via the M drive letter resulted in corruption of the Exchange Store. Clearly it was a hacked-together feature that wasn’t tested properly.

If you ever enjoyed seeing a grown Exchange Server system administrator cry, tell him that his running of a defrag tool on his M drive was equivalent to putting the entire public folder store through a blender.

Not surprisingly, M disappeared soon afterwards.

Meanwhile, the Windows Server team was still trying out new ideas. My favourite appeared in the betas of Server 3.51, wherein Office Structured Storage data files were deconstructed into NTFS Streams. A brief explanation: DOC, XLS and PPT files were in fact all mini file systems, called OLE Structured Storage.