Big Drives, Part 2

I can imagine that after reading part 1 of the ‘Big Drive Problem” one essential question remained unanswered and haunted your thoughts: How big should I make my C:\ drive if I move every dynamic, sensitive or performance related piece of data from it? I intend to answer that question in this post.

Let’s first look at some statistical data from the past few years and after that look at the years you want your server to offer services without disk space problems. There are important things to consider!

Disclaimer
This post assumes the latest figures for Windows Server 2008 are congruent with the figures for Windows NT in the past ten years. While I believe my findings to be true, only time can tell whether they are.

 

Windows NT over the years

Microsoft Windows NT is Microsoft’s family of Operating Systems for businesses. It was first introduced in 1993. Most of us can’t remember Windows NT before version 4.0, although I had the pleasure a couple of years ago to troubleshoot a Windows NT 3.51 Server.

Disk space used for clean installations

Let’s look at the system requirements for members of the Windows NT family since 1997. Since this post is about disk drives I’m most interested in the disk size requirements. I found some useful numbers related to system requirements in Microsoft KnowledgeBase article 304297. Together with the articles it links to it provides an adequate estimate on disk usage after initial installation.

Note
I’m looking at 32-bit x86 versions of the Standard SKU for Windows NT Server, installed on NTFS partitions using default settings. Windows NT 4.0 was installed as a Stand Alone server. I don’t consider the page file as part of the initial installation.

Where Windows NT 4.0 Server (the equivalent to Windows Server, Standard Edition nowadays) installed using 94 MB on the hard disk of our machines in 1997, Windows Server 2008 Beta 3 installs a whopping 5829 MB. Windows 2000 Server and Windows Server 2003, which were released between these two releases, used up 708 MB and a mere 1245 MB on disk. You can clearly see the exponential increasing disk usage for clean installation between these three major Windows NT releases. (NT 4.0, NT 5.x and NT 6.0)

These figures seem to indicate a eightfold growth in disk usage between major Windows NT releases, roughly every four to five years.

Service Packs

You might now have an idea about the size of your initial installation, but remember Service Packs grew in the last ten years as well. Service Packs for the x86 version of Windows NT 4.0 Server were downloads smaller than 40 MB (I only count the service pack files that end with ‘i’.) Windows Server 2003 Service Pack 2 clogged your Internet connection during the time it took to download 372 MB.

While an eightfold growth figure might not scare you anymore after you’ve seen the values for initial installation there is something you might keep an eye on. A Service Pack only contains compacted files that need replacement on your hard disk. The free space on your hard drive size must be sufficient to store the unpacked versions and any temporary files needed for installation. These values apparently weren’t important in the Windows NT 4.0 era since Microsoft didn’t publicize them. Microsoft started telling us these values in the Windows 2000 era because they began to matter. Microsoft clearly stated you needed 710 MB of free space to install Windows 2000 Server Service Pack 2. They also stated you needed up to 1245 MB to install Windows Server 2003 Service Pack 1 and up to 2900 MB to install Windows Server 2003 Service Pack 2. I find these values staggering, because my fresh installation of Windows Server 2003 only used 1245 MB of disk size…

I won’t compare small downloads for Windows NT Service Packs with absurd free space considerations for Windows Server 2003 Service Packs. Just keep in mind you need to supply Windows with more free space than the initial installation size to simply be able to install Service Packs.

 

Installation media

After installation I recommend copying the i386 folder from the installation media to the C:\ drive, effectively creating a C:\i386 folder locally. When I’m done installing and patching the initial Operating System I use this local repository to install roles and/or additional components to the server.

The i386 folder on my non-slipstreamed Windows NT 4.0 Server media amounts to 83,1 MB. The i386 folder on a non-slipstreamed Windows 2000 Server is 317 MB. The Windows Server 2003, Standard Edition CD contained a 487 MB i386 folder. The Windows Server 2008 Beta 3 installation media isn’t a CD anymore. It’s a DVD with roughly 1,7 GB of data…

“the 10% rule”

The main reason we’re looking at disk usage is to avoid the ‘disk full’ scenario. In my book this means to avoid any errors. Microsoft Windows NT by default produces errors when your disks offer less than 10% free space. You can adjust this, but only for all disks, so that practically renders that option useless. The logical choice is to use a 10% safety margin.

 

Best Practice

I tend to look at the complete life cycle for a server. This means that when I install it I think about the way the server will be used during the complete time it’s powered on. Most of the time this means that I look at the roles the server will be performing from the moment I migrate to the server until the moment I migrate it’s functionality to a different server. I consider this a best practice.

In theory

Customers are happy buying a server with four to five years of support, with the right dimensions and redundancy to last five years, when you can say you will configure it to be reliable during this time. Without the need to add hardware it’s already difficult enough to end up with high uptime percentages…

In Practice

Assume we would now install a server with Windows Server 2003 R2, intend to perform an (in-place) upgrade to Windows Server 2008 and intend to deploy Service Packs to keep it up to date. During its lifetime we need to make sure we supply the server with a big enough C:\ drive. You’d be on the safe side configuring your server with a 24 GB C:\ drive if you’d want it to last four years.

Costs

In a time where most of us are installing servers with 12 GB C:\ drives, it might be a bit difficult to explain to your customer or your colleagues you propose a 24 GB C:\ drive for a new server. On the other hand your customer might have had the unpleasant experience of in-place upgraded Windows 2000 Servers with 4 GB C:\ drives, or Windows Server 2003 boxes with 8 GB C:\ drives.

Just remember that hard disk space is rapidly becoming cheaper. You can buy a 300 GB SAS drive now for the same price you could buy a 36,4 GB SCSI drive five years ago…

 

Conclusion

Think carefully about the size of your C:\ drive. Take the following things into consideration:

  • Increasing initial installations
    (94 MB for Windows NT 4.0 Server vs. 5829 MB for Windows Server 2008 Beta 3)
  • Increasing Service Pack download sizes
    (18 MB for Windows NT 4.0 SP 3 vs. 372 MB for Windows Server 2003 SP2)
  • Increasing Service Pack temporary storage needs
    (no comparison made)
  • Increasing Installation media
    (87 MB for Windows NT 4.0 vs. 1,7 GB for Windows Server 2008 Beta 3)

I suggest you supply your servers with 24 GB C:\ drives, when you combine this suggestion with the data placement advice I gave in Part 1 of this series. A 24 GB C:\ drive might sound outlandish, but it isn’t. A big enough C:\ nowadays costs the same as providing a big enough C:\ drive four years ago…

Further reading

System requirements for Microsoft Windows operating systems
Hard disk space requirements for Windows 2000 Server Service Pack 1
Hard disk space requirements for Windows 2000 Server Service Pack 2
Hard disk space requirements for Windows 2000 Server Service Pack 3
Recommended Space Requirements for Windows 2000 Service Pack 4
Hard disk space requirements for Windows Server 2003 Service Pack 1
Hard disk space requirements for Windows Server 2003 Service Pack 2

Series Navigation

<< Big drives, Part 1

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.