Недостаточно места на диске NTFS после серии создания / удаления файлов одинакового размера
Я столкнулся с действительно странной проблемой, работая над большим проектом. Я пишу кучу файлов одинакового размера на раздел (пробовал как RAM-диски, так и виртуальные диски, созданные с помощью diskmgmt.msc). Когда недостаточно свободного места для размещения другого файла (как сообщает GetDiskFreeSpaceExW), Я удаляю один (только один) из ранее созданных и пишу новый. Затем я удаляю другой старый файл и записываю новый, до бесконечности (так что вы можете думать о разделе как о кольцевом буфере файлов одинакового размера). После серии операций записи-удаления (от нескольких сотен до нескольких тысяч) я сталкиваюсь с no free space ошибка при записи нового файла (до этого GetDiskFreeSpaceExW сообщает достаточно места). Я попросил нескольких моих коллег попытаться воспроизвести проблему на их оборудовании, но проблема не всплыла.
Чтобы немного прояснить ситуацию, вот точный алгоритм:
- Выберите размер файла (скажем, S байт)
- Проверьте свободное место с помощью GetDiskFreeSpaceExW
- Если free_space > S: напишите новый файл размера S и перейдите к 2
- Остальное: Удалить один файл и перейти к 2
Важно отметить, что я записываю данные в файлы в блоках размером 4096 байт (проблема может или не может всплыть в зависимости от размера блока). Размер файла составляет 5 МБ. Размер раздела NTFS составляет 21 МБ. Размер кластера составляет 512 В (опять же, изменение этих параметров влияет на результаты). С этими параметрами сбой происходит при создании 684-го файла. Это не зависит от того, использую ли я RAM-диск или виртуальный диск (следовательно, это не проблема конкретной реализации).
Я проанализировал полученные дампы образов дисков после сбоя и обнаружил, что файлы были сильно фрагментированы. Чкдск не сообщает о проблемах ни до, ни после эксперимента. В системных журналах ошибок не обнаружено.
Возможно соответствующие параметры моего нетбука (Dell Inspiron 1110):
- Pentium SU4100, относительно медленный двухъядерный процессор x64 CULV (1,3 ГГц)
- Windows 7 Ultimate x64 edition
- 2 ГБ ОЗУ
Кто-нибудь имеет представление о том, что происходит и как его отладить? Где я могу найти дополнительную информацию? У меня уже нет идей, и мне нужно решить эту проблему как можно скорее...
UPD: проблема возникает при записи данных в файл (т.е. write() не удается), а не когда я создаю файл. Так что, похоже, мне не хватает записей MFT.
UPD2: отвечая на несколько вопросов, которые были заданы
- Раздел является только что отформатированным, следовательно, никаких специфических атрибутов в файлах, никакой структуры каталогов, ничего
- Разрешения по умолчанию
- Нет.lnk, нет жестких ссылок - только файлы, которые я пишу
- Все файлы записываются в корневой каталог, каталоги больше не создаются
- Имена файлов - это просто порядковые номера файлов (то есть 1, 2, 3, ...)
- Альтернативных потоков данных нет, файлы создаются с использованием `fopen()`, записываются с помощью `fwrite()` и закрываются с помощью `fclose ()`
- $ Txf действительно создается
- Нет плохих кластеров, это виртуальный (или RAM) диск
4 ответа
Хороший вопрос NTFS и не вся информация здесь. Что такое структура каталогов? Есть ли файлы LINK на этом? Вы используете сжатие на диске? Объемные теневые копии?
Вы не исчерпываете пространство MFT, так как существует постоянное количество файлов / каталогов. Это означает, что MFT является статическим. Также резервное пространство MFT будет использоваться в сценариях с ограниченным пространством на диске. Я использовал каждый кластер на томе NTFS.
Есть несколько объяснений того, что происходит:
1) Возможно, файл $Log вырос. Это журнал отката.
2) Файл @SII для информации о безопасности файла мог бы увеличиться, если на диске имеются неоднородные разрешения
3) Если некоторые файлы этого тома имеют файлы.lnk/ shortcut, указывающие на них, система помещает GUID для каждой цели в индекс. (вы получаете файлы.lnk, если дважды щелкнуть файл в проводнике - в последних документах!)
4) структура каталогов НЕ статична (или имена файлов не одинаковы по длине), размер буферов каталогов $index может увеличиться.
5) Если у вас есть системный том directroy на этом диске, у вас могут быть теневые копии томов и другие данные ОС.
6) Альтернативные потоки данных не отображаются в размере файла. Есть ли?
7) TxF - под Vista и выше может быть транзакционный уровень, который занимает переменное пространство.
8) плохие кластеры? Кластеры могут выйти из строя (но chkdsk может это заметить..)
9) Файлы становятся фрагментированными, и список фрагментов вместе с другими метаданными слишком велик, чтобы поместиться в запись MFT (маловероятно, если ваши файлы маленькие и у вас нет длинных файлов)
10) Использование жестких ссылок также помещает больше данных на диск.
Я перечислил все это как ссылку для других людей!
Последнее замечание - иногда вы можете создавать и записывать небольшой файл, даже если на нем свободно 0 байт, поскольку резидентные файлы NTFS занимают только запись MFT (они возвращают удаленный бесплатный)
FS имеет свои накладные расходы, которые вы не учитываете. Эти издержки не постоянны, поэтому, удаляя / записывая файлы, вы можете вызывать фрагментацию. Другими словами, "5 МБ свободного места" не означает, что вы можете записать 5 МБ на диск.
Предполагая, что ваша реализация верна и ваши коллеги не могут воспроизвести проблему, возможно, у вашего MFT недостаточно места.
По умолчанию Windows XP резервирует 12,5 процента каждого тома NTFS (область, называемая зоной MFT) для исключительного использования MFT. Поэтому, если вы планируете хранить тонны небольших файлов (скажем, менее 8 КБ) на томе, в MFT может не хватить места до того, как освободится свободное место на томе, и результатом будет фрагментация MFT.
Из Технета
Во-первых, MFT не сжимается даже при удалении файлов и каталогов с тома; вместо этого MFT отмечает FRS, чтобы отразить удаление. Во-вторых, NTFS хранит очень маленькие файлы в MFT FRS, которые ссылаются на файлы. Хотя эта настройка обеспечивает выигрыш в производительности для этих файлов, она может привести к чрезмерному росту MFT, если том содержит много таких файлов.
Хотя неудивительно, что отключение TXF исправило бы это (TXF - это только один компонент файловой системы, использующий пространство на томе), следует учитывать две вещи. Во-первых, и более того, в действительности, вы можете быть осторожны с отключением. (Другие компоненты могут зависеть от этого; Центр обновления Windows является одним из таких компонентов, хотя он должен заботиться только о томе системы.)
Еще одна вещь, которую следует учитывать, это то, что это, как правило, хрупкая модель. Файловая система имеет некоторые предположения о том, что она может потреблять. Например, индексы будут расти (с предопределенными приращениями, могут изменяться), и они могут не уменьшаться способами, которые вы считаете предсказуемыми. Кроме того, индекс дескриптора безопасности, вероятно, будет продолжать расти.
Другое замечание выше о теневых копиях - это то, что всегда нужно помнить.
FWIW Файл $Log не будет расти автоматически.