Как я могу проверить фактический размер, используемый в каталоге NTFS со многими жесткими ссылками?

Question

На томе WinFS NTFS я использую cwrsync, который правильно поддерживает --link-dest для создания резервных копий типа "моментальный снимок". Так что я:

z:\backups\2010-11-28\cygdrive\c\Users\...
z:\backups\2010-12-02\cygdrive\c\Users\...

Содержимое 2010-12-02 - это в основном жесткие ссылки на файлы в каталоге 2010-11-28, но есть несколько новых или измененных файлов только в 2010-12-02. В linux утилита du сообщает мне фактический размер каждого добавочного снимка. В Windows explorer и du under cygwin одурачены жесткими ссылками и показывают, что 2010-12-02 занимает немного больше места, чем 2010-11-28.

Существует ли утилита Windows, которая покажет правильное пространство, используемое в действительности?

Answer 1

Попробуйте использовать Sysinternals Disk Usage (иначе называемый du), в частности, с помощью флагов -u и -v будут учитываться только уникальные вхождения, и будет отображаться использование каждой папки в процессе работы.

Насколько я знаю, файловая система не показывает разницы между исходным файлом и жесткой ссылкой (это действительно точка жесткой ссылки), поэтому вы не можете сбрасывать со счетов их на основе папок, но нужно сделать это сравнительно.

Для тестирования я создал случайную папку с 6 файлами в. Клонировал все это. Затем создали несколько жестких и мягких ссылок внутри первой папки, чтобы ссылаться на другие файлы в первой папке, а также некоторые во второй.

Запуск du -u -v testFld приводит к (обратите внимание, что значения рядом с папками указаны в КиБ):

       104  <path>\testFld\A
        54  <path>\testFld\B
       149  <path>\testFld

Totals:
Files:        12
Directories:  2
Size:         162,794 bytes
Size on disk: 162,794 bytes

Запуск du -u -v testFld\a приводит к:

104  <path>\testFld\a
...

Запуск du -u -v testFld\b приводит к:

74   <path>\testFld\b
...

Заметить несоответствие?
Символические ссылки в A, относящиеся к файлам в B, учитываются только в A во время "полного" прогона, а B возвращает только 54 (даже если файлы изначально были в B и жестко связаны с A). Когда вы измеряете B отдельно (или, если вы не используете уникальный флаг -u ), он будет считать "полную" меру 74.

Answer 2

PowerShell 5 может быть вариантом. Он доступен для Windows 7, но я тестировал его только на Server 2012 R2 с апрельским обзором 2015 года.

Поставщик файловой системы в PowerShell 5 имеет два новых свойства LinkType и Target:

ls taskmgr.exe | fl LinkType,Target

это возвращает:

LinkType : HardLink
Target   : C:\Windows\WinSxS\amd64_microsoft-windows-advancedtaskmanager_..._6.3.9600.17..2\Taskmgr.exe

Так что теперь я могу показать только все файлы в system32, которые не являются жесткими ссылками:

cd $env:SystemRoot\System32
ls -Recurse -File -force -ErrorAction SilentlyContinue | ? LinkType -ne HardLink | Measure-Object -Property Length -Sum

это возвращает:

Count    : 844
Sum      : 502,486,831

Вы можете сравнить это со всеми файлами:

ls -Recurse -File -force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum

Count    : 14092
Sum      : 2,538,256,262

Таким образом, более 13 000 файлов с 2 ГБ + являются жесткими ссылками

Answer 3

TreeSize Professional (~ $ 55, 30-дневная пробная версия) утверждает, что искажает место на жестком диске NTFS. Быстрое испытание, кажется, подтверждает это.

Поддержка жестких ссылок не включена "из коробки": перейдите в Инструменты> Параметры> Сканировать, повторно отсканировать, затем использовать Ctrl-1 и Ctrl-2 для переключения между размером и выделенным пространством. Выделенное - это фактическое используемое пространство, а Size - это статистика, обычно сообщаемая другими программами.

Существует снижение производительности за включение поддержки жестких ссылок (и символических ссылок и монтирования тоже, если вы этого хотите). Цветовая палитра бросается в глаза на мой вкус, но это, кажется, является нормой для курса в этом жанре. Также будьте осторожны при щелчке в области диаграммы блока - легко случайно переместить папку с ошибочным перетаскиванием, когда вы только хотели ее развернуть.

Answer 4

Я также делаю некоторые исследования по этому вопросу. Вот результаты, которые я обнаружил.

Размер папки, содержащей жестко связанные файлы в NTFS, можно рассматривать в трех разных значениях:

1. Размер, включая размеры всех жестко связанных файлов (который показан WE).
2. Размер уникальных файлов только с точки зрения текущей папки.
3. Размер уникальных файлов только с точки зрения всего диска.

Число 2 - это то, что отображается TreeSize Professional на вкладке "Сведения" в столбце "Выделено", если включена опция "Отслеживать жесткие ссылки NTFS".

Вот пример для папки winsxs (7.5Gb вместо 10):

Получение значения № 3 - все еще вопрос для меня. Хотя я смог получить нижнюю границу, используя Total Commander с плагином NL_Info. У меня есть размер, занимаемый файлами, которые имеют только одну жесткую ссылку (уникальные файлы). Это было около 5 Гб для данного примера.

Таким образом, пытаясь расширить harrymc ответ или сказать другими словами.

Answer 5

Я думаю, что некоторые факты должны быть установлены прямо здесь.

Windows не может "обнаружить" жесткие ссылки, поскольку каждый файл на самом деле является жесткой ссылкой на группу байтов на диске.

Инструмент du обнаруживает дубликаты, но это также ложно, так как если папка A содержит файлы, а B содержит только жесткие ссылки на файлы в A, то du из A и du из B будут возвращать один и тот же ответ - размер файлов, поступающих изначально от А, но эти файлы теперь тоже в Б.

Это действительно правильно, так как, например, если вы удалили A, то его файлы не будут удалены на диске, потому что на них по-прежнему ссылается B. С жесткими ссылками, какой файл является источником, а какой является жесткой ссылкой совершенно произвольно и бессмысленно.

Такие продукты, как du, будут отображать каталог при дисконтировании дубликатов. Это будет работать, только если все файлы и жесткие ссылки содержатся в одном каталоге. Многие продукты со списком папок делают это.

Вывод: с жесткими ссылками вопрос о «фактическом размере, используемом в каталоге NTFS» не имеет смысла.