次の方法で共有


General guidance on disk provisioning for WinSXS growth

Seems like this question has come up a lot this past week at work:

How much space should I plan to provision for my new Vista, 2008, Win7, R2 installs? 

This questions comes up in one of two forms.  Either an admin is planning a new deployment and is just curious, or more likely, machines that were provisioned previously are now running out of disk space because the intial disk roll out was too small (usually these systems are under 20GB). 

My answer to this question is always the same: 40GB

Why 40?  Well it gives you good space growth for the servicing directory, which should be in the range of 7-15GB on most machines.  Keep in mind that as you patch your systems and add new roles and features, the WinSXS directory will grow in size.  Also, 40GB allows you to properly keep a reasonable page file on the system.  We see more and more client systems with 6+GB of physical RAM these days in workstation class machines and if you ever encounter an issue such as bugchecks on those systems, you want to be able to make sure you can properly capture a memory dump so we can look at it.  On server class machines, page files are typically moved from the root, so 40GB is a nice enough number to just secure space for growth without too much worry about space concerns

I know I am also asked a lot about what causes the growth in WinSXS and I've written about it in the past on my teams site: https://blogs.technet.com/b/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspx .  If you have to reclaim space, your options are fairly limited.  On Vista and 2008 machines with SP2, you can use the COMPCLN utility to make the service pack permanent and reclaim some space.  If you've already done that, you can force scavenging on the servicing directories by adding/removing a component (I usually use TelNet client because its small and quick).  On Win7 and R2 machines, we auto scavenge at specific intervals, so this isnt necessary and your WinSXS directory is probably correctly reflecting its size.

Hope this helps

--Joseph

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    @Stretor; Assuming you're on SP1 I have information on that here: blogs.technet.com/.../how-to-reclaim-space-after-applying-service-pack-1.aspx

  • Anonymous
    January 01, 2003
    @Mike;  This entry isnt targetted towards consumers.  It's meant as a guideline for admins looking to conserve their provisioned storage in virtual environments (for the most part).  If you're going to utilize the Win7 installation as a full installation and store everything on that local volume then drive space considerations exponentially increase with installed applications/data.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    only in Windows 8 MS allows an automatic removal of replaced updates.

  • Anonymous
    January 01, 2003
    @Frank; You would be getting close to the limit of what I consider reasonable.  Have you ever used VSP1CLN or COMPCLN to mark the Service Pack permanent on the system?  If not, you may want to consider doing that to remove some unneeded files from the machine and reclaim some space. --Joseph

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    @Frank Uninstall superseded updates. I did this on my friend Vista Sp2 HP and this saved 3GB of space by oly removing the old cummulative IE updates.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    No, there are switches in DISM for SP1 that will allow you to make the service pack permanent, thereby recovering the space somewhat (similar to VSP1CLN and COMPCLN in Vista/2008).  I'm under the assumption that you're using a netbook with a 16GB SSD, otherwise, if you're running out of space there might be another problem.  I could see a 16GB SSD with Windows, Office, other apps and data becoming confined for disk space.

  • Anonymous
    January 01, 2003
    Drew; 40GB should be fine, again, this assumes that you arent installing a ton of applications into the system directory.  The recommendation stands for x64 or x86 architectures. The KB you mention above is still valid for people not running the latest service packs but isnt as relevant for Vista SP2 and Win7 systems.

  • Anonymous
    June 12, 2010
    I have a question. Suppose I install Windows 7 then I install lots and lots of pre-SP1 patches. Then WinSxS size will obviously grow. Then later when Windows 7 SP1 comes up, I install that and later run Compcln. Will it clean only the files to make SP1 permanent or will it also clean all the space used by pre-SP1 patches which will be anyway part of SP1? Or does installing SP1 clean up the disk space used by pre-SP1 patches?

  • Anonymous
    July 28, 2010
    Now that Windows 7 SP1 is going to beta, can you try to get an answer to this question?  In particular, can we finally recover some of the WinSxS bloat once we install SP1?  I have three NetBooks in the family that are basically unable to run Windows update any longer because they're more or less out of space.  I'll probably have to uninstall Office on all of them just to get SP1 installed...Grrrrrr.... It should be an option to clean out EVERY patch and service pack, at the expense of doing an uninstall, which in almost two decades of using Windows, I've never had to do once...

  • Anonymous
    November 25, 2010
    So VISTA forces a re-install after time... It is a shame with all the money they get, for making nothing but code and a plastic disc, that they can't get the OS to empower the user and be quicker, each time it's revamped. I guess it's time for me to setup my Windows client as a VM, get it to the state I can do what I want, then never save the changes. Of course files would have to be saved onto another drive but that could be done. I built my own PC and purchased VISTA 64 and have now re-installed about 5 times. At least the clean installs are easier than xp (can run unattended). The company that sold it were OK about my complaints and sent me a 32 bit version for nothing. I wouldn't have known about all this if it wasn't for the Win7 upgrade advisor telling me I was low on disk space, which is odd as only Windows resides on my SSD. Temp folder, recycle bin and everything else removed to another drive. So this was odd. I remembered when I had 30Gig (half) of my SSD free. So I used treeview and found what was eating my SSD and now know the only way to deal with it is to not deal with it, and certainly not upgrade to 7. That would make things much worse!

  • Anonymous
    February 17, 2011
    Slightly off topic: If i were going to build a system and move the profiles directory to D:Users, i would have to estimate a size for C:, that was not going to either limit growth or waste too much space. So based on this post i would have to make; C: = 40GB + %Program Files% I wonder if there is any handy data or MS telemetry on the typical size of %ProgramFiles% or Users, on both 32 and 64bit platforms? Btw, has seperating user data from %windir% and %ProgramFiles% ever been seriously considered at Microsoft, as say an Advanced option in Windows Setup?

  • Anonymous
    February 19, 2011
    The comment has been removed

  • Anonymous
    February 21, 2011
    I'll adopt 40GB as part of my baseline configuration and see how it goes. However, i'll remain conscious of slighly disconcerting stories like this: www.shdon.com/.../windows-update-woes "The update function had gone haywire, having stored close to a hundred thousand files, making the C:WindowsSoftwareDistributionDownload folder a ridiculous 22GB in size, accounting for some 40% of all allocated disk space." (55% of 40GB). Ok on your second point, although to repeat myself, Windows 7 doco still refers this pre-Vista SP1 relevant article: technet.microsoft.com/.../ff715936(WS.10).aspx Again, slightly disconcerting. At least it was.

  • Anonymous
    February 21, 2011
    "The softwaredist story mentioned above is rare and easily solved by renaming the folder and deleting the contents." Yes, your right. Rare problems like that should be dealt with directly, not indirectly by adding 'error space' to %systemdrive%.

  • Anonymous
    April 04, 2011
    40 gigs is great if you're not going to use it. Or if you want to spend lots of time moving folders from their default locations,   I have a laptop dual booting xp and 7. Use xp all the time; rarely use 7, and i don't even update it that often.  The 7 partition is about 43 gigs.  its windows folder is over 10 gigs, of which 4.4 gigs is winsxs.   This installation will be pretty much useless for anything except looking over windows 7.  If you are going to use your documents folder and your libraries as other than links, if you are going to install a lot of progs and are are going to check out a variety of other progs, you will need at least 200 gigs.  The net is littered with complaints from  40-64 gig ssd users who are running out of space under win7.

  • Anonymous
    May 10, 2011
    Joscon, there is or not a solution for cleanup the winsxs on windows 7 ? What is the magic command ? I've read about vsp1cln.exe and compcln for vista and for windows 7 ? I've 14Gb of winsxs and just installed seven (from clean) about two months ago ! :-(( hope in a real solution from MS ...

  • Anonymous
    June 19, 2011
    After running Windows 7 for a while I think the 40GB recommendation is a good one.  With my 30 GB SSD I'm just on the edge of a continual struggle to maintain free space.  Another 10 GB would probably be perfect.

  • Anonymous
    February 11, 2012
    Hi, Is 15GB a reasonable size for a Vista 32 Home Premium installation? Regards, Frank

  • Anonymous
    February 11, 2012
    Hi again, I meant 15 GB for only the winsxs folder, analysed with windirstat. ciao, Frank

  • Anonymous
    June 21, 2013
    Uninstall superseded updates is the correct answer. I need a tool that can uninstall all superseded updates.