Сегодня обнаружил, что на SSD, размер которого 120Gb, теперь свободно лишь 9 Gb. Резервные копии файлов обновлений занимали всего 2Gb и мне стало интересно, где же остальное свободное место…
Виновником были образы виртуальных машин, которые создавались под учеткой админа для тестирования загрузки с USB, но это всего 25 GB, вот я и решил выяснить, где все остальное…
Лидером оказалась папка WinSxS, она занимала 14GB. Правда, если быть честным, то стоит заметить, что истинный размер WinSxS несколько меньше, т.к. там содержится много хардлинков на файлы внутри.
Вот пример:
C:\Windows>fsutil hardlink list bfsvc.exe \Windows\bfsvc.exe \Windows\winsxs\amd64_microsoft-windows-b..vironment-servicing_31bf3856ad364e35_6.1.7601.17514_none_843a86a1bc33fcd1\bfsvc.exe
Как видно, на файл bfsvc.exe создано 2 жесткие ссылки, одна из которых указывает на файл в одной из папок, расположенных в C:\Windows\winsxs\
Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore
В Windows 8.1 и выше можно удалить неиспользуемые компоненты этой папки:
Dism.exe /online /Cleanup-Image /StartComponentCleanup
Можно пойти дальше и удалить все замененные версии для всех компонентов в хранилище компонентов:
Dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase
Помимо этого можно сделать SP перманентным. Будут удалены все резервные компоненты, необходимые для удаления пакета обновления:
Dism.exe /online /Cleanup-Image /SPSuperseded
MSDN
Вообще можно не допускать роста этой папки просто не устанавливая лишних приложений. Поскольку каждое новое приложение добавляет в эту папку «очень важные и нужные» файлы. Я боюсь, что даже если вы удалите лишнее приложение из системы, все равно некоторые файлы не будут корректно вычищены. А вообще размер этой папки даже на только что установленной системе (Windows 7 SP1 со всеми хотфиксами) равен 10 GB! Так что скорее всего придется смириться с ее требованиями и отдать ей как минимум 10 гигабайт SSD :)
На втором месте была папка Installer (11GB), которая относилась непосредственно к ОБНОВЛЕНИЯМ. То есть в сумме файлы для обновлений у меня отожрали почти 25 ГИГАБАЙТ. Даже не так. Не файлы обновлений, а опять же всякий мусор (для меня), который необходим системе для откатов, в случае удаления одного из обновлений. Даже если вы захотите удалить не обновление, а установленное СТОРОННЕЕ приложение, то система будет сверяться с информацией этих папок. В случае, если что-то нужное там не будет найдено, приложение удалить или обновить не получится.
Есть небольшая статья, посвященная этому вопросу. Если коротко, то эти папки удалять нельзя. Возможно, но нельзя из-за последствий. В комментариях много помой было вылито на голову MS (справедливо на мой взгляд). Я не уверен, что в Windows 10 решили эту проблему, хотя был бы очень рад…
В качестве одного из способа ее решения, было предложено следующее:
1. Убедиться, что в данный момент не запущена никакая установка программы или обновления.
2. Скопировать C:\Windows\Installer на другой диск (например, в D:\C_DRIVE\Windows\Installer)
*. Можно было конечно просто вырезать и вставить папку в новое место, но в этом случае пришлось бы дополнительно становиться владельцем тысяч файлов.
3. Удаляем папку Installer:
rmdir /s /q C:\Windows\Installer
4. Создаем символьную ссылку на папку с диска D:
mklink /D C:\Windows\Installer D:\C_DRIVE\Windows\Installer
Получается так:
C:\Windows\system32>rmdir /s /q C:\Windows\Installer C:\Windows\system32>mklink /D C:\Windows\Installer D:\C_DRIVE\Windows\Installer symbolic link created for C:\Windows\Installer <<===>> D:\C_DRIVE\Windows\Installer
Таким образом мы перенесем папку Installer на другой диск. Поскольку это папка с установочными файлами, то ее расположение на медленном диске не скажется на производительности.
Для проверки можно попытаться зайти через Проводник на диск С в папку Installer. Если вы сможете ее открыть, значит путь назначения указан верно.
Пробую удалить Microsoft SQL Server 2014 T-SQL Language Service — получилось. Если бы были какие-то проблемы с папкой Installer, то программа бы не удалилась.
Папка ProgramData\Package Cache
Эта папка создается при установке Visual Studio. Судя по всему ее функции примерно такие же, как в случае, описанном выше — она нужна для того, чтобы можно было Восстановить/Изменить/Удалить компоненты Visual Studio. Ее размер составляет 2,5 GB. Это при том, что дистрибутив Visual Studio Community 2015 весит 6,15 GB. Т.е. не на столько уж больше, чтобы мне хранить и эти файлы и дистрибутив. Поэтому его также перенесу на диск D.
1. Копируем папку C:\ProgramData\Package Cache на диск D: в папку D:\C_DRIVE\ProgramData\Package Cache
2. Удаляем папку на диске C: и создаем символьную ссылку на папку с диска D:
C:\>rmdir /s /q "C:\ProgramData\Package Cache" C:\>mklink /D "C:\ProgramData\Package Cache" "D:\C_DRIVE\ProgramData\Package Cache" symbolic link created for C:\ProgramData\Package Cache <<===>> D:\C_DRIVE\ProgramData\Package Cache
Папка Windows
Открываю папку Windows (напоминаю, у меня Windows 7). Вижу подпапку Chipset, в ней содержатся папки Win7_XP, Win8, Win8.1 и три файла: AsusSetup.exe, AsusSetup.exe.manifest, AsusSetup.ini. Все это занимает 305 МБ. Зачем в папке Windows папка с файлами установки драйверов чипсета, я не понимаю, поэтому удалил их оттуда. Если будет нужно, установлю с диска D, где у меня хранятся все драйвера и дистрибутивы. Также для «работы» было создано задание в планировщике в разделе ASUS, под названием i-Setup210951. У него был только один триггер: при входе в систему каждого пользователя запускалось C:\Windows\Win7_XP\AsusSetup.exe -reboot -log210951. Если обратить внимание, то это другая папка! Размер этой папки 253 МБ. То есть вместе с той папкой, в папке Windows у меня было две папки с файлами УСТАНОВКИ драйвера чипсета (которые уже давно были установлены, поэтому мне не нужны!!!). Общий размер этих двух папок и их подпапок составлял 558 МБ! Т.е. больше половины гигабайта! В итоге я удалил эти две папки, перезагрузил компьютер и ничего плохого не произошло.
Файл DataStore.edb, расположен в папке C:\Windows\SoftwareDistribution\DataStore. Его размер 904 МБ. Это база данных, в которой содержится история всех обновлений установленной версии Windows, включая те обновления, которые только стоят в очереди. Удалять его тоже не нужно, хотя бы потому, что потом он все равно будет создан заново. Можно запустить его дефрагментацию и попытаться уменьшить его размер (перед этим нужно остановить службу wuauserv, а после дефрагментации базы запустить заново):
C:\ProgramData\Package Cache>esentutl /d %windir%\softwaredistribution\datastore\datastore.edb Extensible Storage Engine Utilities for Microsoft(R) Windows(R) Version 6.1 Copyright (C) Microsoft Corporation. All Rights Reserved. Initiating DEFRAGMENTATION mode... Database: C:\Windows\softwaredistribution\datastore\datastore.edb Defragmentation Status (% complete) 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| ................................................... Moving 'TEMPDFRG5164.EDB' to 'C:\Windows\softwaredistribution\datastore\DataStore.edb'... File Copy Status (% complete) 0 10 20 30 40 50 60 70 80 90 100 |----|----|----|----|----|----|----|----|----|----| ................................................... Note: It is recommended that you immediately perform a full backup of this database. If you restore a backup made before the defragmentation, the database will be rolled back to the state it was in at the time of that backup. Operation completed successfully in 44.413 seconds.
В итоге размер файла datastore.edb уменьшился с 904 МБ до 900 МБ. Разница не настолько большая, чтобы этот шаг стоило выполнять (если конечно не критически небольшой размер системного SSD, где каждый мегабайт на счету.
После того, как я все «подчистил», у меня осталось свободно примерно 39 GB (за вычетом образа виртуальной машины, освободилось примерно 10 GB).
