Я создал копию системы на виртуальной машине VMWare (v7), размер 7,11 ГБ в сжатом виде, 70 ГБ в несжатом виде (извините, система на французском языке!), вход: adminstrateur и пароль: T3st https://mega.co.nz/#!l981ACQK!LnLFiUD5-MqPI9PnoOEpb_BiERkPe6W3PFa_x8dc_cE
На моем жестком диске отсутствует 40 ГБ, и я перепробовал множество способов отследить это, но безуспешно ( chkdsk /r /f, Defrag, WinDirStat, Space sniffer, Boot on Windows Defender offline, GMER 2.1.1 rootkit removal, streams, vssadmin, dism и т. д.). Кстати, программы были запущены как администратор и система
Подробную информацию о дисковом пространстве можно посмотреть здесь:
Единственная информация, которую я смог найти, находится в chksdsk, где говорится, что 40 ГБ используются системой:
Le nom de volume est System.
Avertissement ! Le paramètre F n'a pas été spécifié.
Exécution de CHKDSK en mode lecture seule.
CHKDSK est en train de vérifier les fichiers (étape 1 sur 3)...
46402816 enregistrements de fichier traités.
La vérification des fichiers est terminée.
793 enregistrements de grand fichier traités.
0 enregistrements de fichier incorrect traités.
0 enregistrements EA traités.
84 enregistrements d'analyse traités.
CHKDSK est en train de vérifier les index (étape 2 sur 3)...
46451532 entrées d'index traitées.
La vérification des index est terminée.
0 fichiers non indexés analysés.
0 fichiers non indéxés récupérés.
CHKDSK est en train de vérifier les descripteurs de sécurité (étape 3 sur 3)
46402816 SD/SID de fichiers traités.
La vérification des descripteurs de sécurité est terminée.
24359 fichiers de données traités.
CHKDSK vérifie le journal USN...
100 % effectués. (1212416 octets USN sur 1216272 traités)
1216272 octets USN traités.
Vérification du journal USN terminée.
Windows a vérifié le système de fichiers sans trouver de problème.
157701119 Ko d'espace disque au total.
26568260 Ko dans 260039 fichiers.
130984 Ko dans 24360 index.
0 Ko dans des secteurs défectueux.
46482335 Ko utilisés par le système.
65536 Ko occupés par le fichier journal.
84519540 Ko disponibles sur le disque.
4096 octets dans chaque unité d'allocation.
39425279 unités d'allocation au total sur le disque.
21129885 unités d'allocation disponibles sur le disque.
( 46482335 Ko utilisés par le systèmeозначает 46 ГБ, используемых системой)
Похоже, его также нет в папке System Volume Information:
Diskpart показывает, что это только один раздел:
Я также попытался загрузить Linux Debian Live CD, чтобы проверить файлы на жестком диске и целостность NTFS:
результат "du -xks ./* | sort -n" (все в порядке)
0 ./Documents and Settings
1 ./autorun.inf
1 ./boot.ini.1.cache
1 ./boot.ini.cache
1 ./boot.ini..cache
8 ./BOOTSECT.BAK
16 ./cleanmem_log.txt
22 ./SRVPRB
53 ./SRVLOG
234 ./$Recycle.Bin
376 ./bootmgr
504 ./Config.Msi
916 ./_icon
971 ./SRVSCRIPT
2443 ./SRVTOOL
3376 ./System Volume Information
3792 ./inetpub
15436 ./Boot
19636 ./SRVWEB
169092 ./Recovery
281139 ./ProgramData
513829 ./SRVINFO
1421744 ./Program Files (x86)
1543517 ./Users
2877066 ./Program Files
4197856 ./SRVFPT
14981405 ./Windows
ntfsfix & ntfsfix -d говорят, что все в порядке
но ntfsck возвращает сигналы следующей ошибки: ошибка получения значения бита для записи {offset value}
в гугле всего 2 тыс. результатов, некоторые из них указывают на источник ntfsck, остальные, похоже, не имеют отношения к делу...
В: Как мне избавиться от этого пространства, используемого системой?
еще немного информации:
- система взята из конвертера VMware, исходная система (физическая) имеет ту же проблему с пространством
- диск был сжат с помощью EASEUS Partition Master, но проблема присутствовала и раньше
- Когда я сжимаю виртуальную машину, я получаю архив tar.gz размером 14 Гбайт, как будто те 40 Гбайт были пустыми.
РЕДАКТИРОВАТЬ:
Использованное пространство было обнаружено в MFT, но ни один инструмент не помог бы от него избавиться.
решение1
Вы пробовали запустить spacesnifferот имени администратора, как предлагает HopelessN00b в комментариях к вашему вопросу? Обычно большие неизвестные проясняются, и, вероятно, вы обнаружите, что C:\Windows\WinSxSвиновником является . Это то место, где Windows хранит разные версии .DLLфайлов, пытаясь избежать ада DLL в старые времена. Вы можете немного почистить его, выполнив это из командной строки с правами администратора:
Dism.exe /online /Cleanup-Image /StartComponentCleanup- это запускает очистку всех файлов в папке WinSxS. В зависимости от того, что у вас установлено, это может сэкономить немного или довольно много места.
Проверитьэтот битот MS по этому вопросу. Также обратите внимание, что довольно часто команда завершается сбоем с некоторым кодом ошибки. Обычно это означает, что в папке есть ожидающие операции (например, обновления Windows), которые необходимо завершить. В частности, если есть файл с именем C:\Windows\WinSxS\pending.xml, он, вероятно, не сработает. Дайте всем обновлениям установиться, возможно, выполните перезагрузку и попробуйте снова. Надеюсь, это поможет!
решение2
Я скачал виртуальную машину и загрузил ее на сервер. Первое, что я заметил, — диск C был сжат. Если ваш физический сервер такой, распакуйте диск. Это мало что даст.
После распаковки я убедился, что вижу то же, что и вы. Я также добавил дисковое пространство, чтобы оно соответствовало вашим 150 ГБ. Затем я установил Defraggler Portable и проанализировал диск. Я начал просматривать сектора, чтобы узнать, какие файлы там находятся, и заметил, что $MFT занимает много места. После небольшого поиска я обнаружил, что утилита CCleaner Drive Wiper может это исправить.
Я начал очистку свободного пространства (1 проход). Программное обеспечение показывает "Очистить свободное пространство MFT", но задача будет выполняться около 24 часов. Я дам ей поработать и отчитаюсь.
Если поискать, можно найти много информации о $MFT и CCleaner. Возможно, вы найдете момент «эврики», который поможет вам понять, как это вообще произошло. На данный момент я могу только предполагать.
Обновление 1: Процесс занял больше времени, чем ожидалось, и я попытался повысить производительность виртуальной машины, но индикатор выполнения остановился, а оставшееся время увеличилось. Я пересобрал виртуальную машину с большим количеством ресурсов, но это, похоже, не помогло. Один из доступных вариантов: сделать резервную копию диска C, и если резервная копия находится в диапазоне 18-19 ГБ, отформатировать или стереть раздел C и восстановить резервную копию. Я подозреваю, что сторонний дисковый инструмент несет ответственность за то, что файлы $MFT находятся в таком состоянии.
Обновление 2:
Все, что я смог сделать, это показать, что занимает место. Я не смог его освободить. Вероятно, есть платные инструменты, которые могут помочь. Если вы знаете, какое программное обеспечение для разбиения на разделы было в системе до EASEUS, это также может помочь в вашем деле. На приведенном выше снимке экрана «64% диска» основаны на 68 ГБ виртуальной машины, а не на полном разделе размером 150 ГБ, который у вас есть.
решение3
Это интересная проблема. Я подозреваю, что это какой-то артефакт из физической системы, который был виртуализирован, но не поддается обнаружению, поскольку физическая причина больше не присутствует.
Вот два примера:
- плохие блоки на физическом диске, которые VMware Converter смог распознать и обойти, но теперь плохие блоки являются частью файла .vmdk, однако они ненастоящийплохие блоки, поскольку VMware Converter мог прибегнуть к копированию на уровне файлов, поскольку копирование на уровне битов не удалось
- некоторые виды теневых копий, которые могли быть потеряны их приложением или нераспознаваемы на физической системе из-за проблем с записью VSS
Вот что я бы попробовал:
Если у вас все еще есть физическая система, проведите полный анализ и там. За исключением, может быть, вы уже сделали это и попробовали виртуализацию, чтобы посмотреть, исправит ли это проблему.
Если вы создаете резервные копии образов внутри виртуальной машины, попробуйте полностью восстановить виртуальную машину на тестовой виртуальной машине и повторить анализ.
Если вы еще не используете его для резервного копирования, попробуйте сделать еще одну резервную копию образа физической и виртуальной систем с помощью ShadowProtect. Это стоит денег, но вы можете установить полнофункциональную 30-дневную пробную версию, которая просто станет неактивной после окончания пробного периода.
Вам нужно будет перезагрузить систему, прежде чем ShadowProtect позволит вам сделать резервную копию системного тома. После того, как вы сделаете резервную копию, вы также можете попробовать Hardware Independent Restore, чтобы восстановить систему (вам нужно будет купить ShadowProtect IT Edition; моя компания использует его, и он того стоит, но вы, возможно, ищете бесплатные решения, поэтому HIR вам не подойдет).
- http://www.shadowprotect.com/shadowprotect-backup-software-downloads
- http://www.storagecraft.com/support/book/storagecraft-recovery-environment-user-guide/restoring-system-volume
Две причины попробовать ShadowProtect:
- у него есть совершенно отдельные VSS-писатели, которые он устанавливает, чтобы добраться до файловой системы. Я использовал ShadowProtect в системах, где любое другое программное обеспечение для резервного копирования, которое я могу придумать, не будет работать, потому что собственные VSS-писатели Windows повреждены
- ShadowProtect обладает чрезвычайно мощным сжатием, которое отсеивает посторонние данные. Обычно я вижу степень сжатия от 50% до 60% при резервном копировании виртуальных серверов. Возможно, он сможет отсеять и эти 40 ГБ мусора.
Мне интересно, докопаетесь ли вы до сути.
решение4
место занято, скорее всего, точками восстановления. Попробуйте удалить точки восстановления для этого диска в разделе «Управление системой» - «Система» - «Дополнительные параметры» - «Вкладка «Защита компьютера» - кнопка «Настроить» - кнопка «Удалить», и вы увидите, как недоступное пространство исчезает.