# бомба от McAfee

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

 

Ясно что будет...
И так считаем: в NTFS при размере тома более 2GB размер кластера составляет 4 Kb; если один мелкий файл занимает один кластер, а их 50 млн, то получим: 200 млн Kb = 195312.5 Mb = 190.7 GB
В итоге получаем что мелкие файлы забьют около 200GB на диске, что при нынешних объёмах HD — не так критично.

 

Su_Sun_Yin
ты попутал ntfs с fat ) в ntfs мелкие файлы не занимают отдельный кластер, а простое переполнение диска в нормальной системе не должно приволить к необходимости его переформатировать )

 

Думаю ключевое слово - "в одной папке". Файлы в папке индексируются. Возможно, при таком количестве где-то что-то переполнилось в индексах.

 

Su_Sun_Yin
Y_Mur
for every file NTFS creates FILE_RECORD stored inside $MFT. when you delete the file, FILE_RECORD is marked as "no used" and could be reused for newly created files, but if we have created a million files, and FILE_RECORD size is... I don't remember... two cluster? or about... well, $MTF becomes just huge. and no way to get wasted space back so, there is an attack. NTFS bomb. you just creates as many file as you only can and ops!!! surprise!!! NTFS keeps small files inside $MTF and never makes it smaller. so, you delete all files. but... free space is zero, disk is full

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

и вы неверно считали. не размер кластера надо брать, а размер FILE_RECORD. мелкие файлы хранятся внутри $MFT

 

Могу предположить что с MFT бяка случилась.

 

Опередили, пока думал

 

http://www.xakep.ru/magazine/xa/116/130/1.asp

Как неудобно без редактирования, чем оно было плохо?

 

Похоже только форматирование спасет в таком случае.

 

stallker
На автора смотрел?

 

Да, обратил внимание.

 

stallker
если проодолжать цитирование, то:

По умолчанию при форматировании диска операционная система резервирует под MFT-файл 10% от неформатной емкости тома, высвобождая эту область только при заполнении диска более чем на 90%. Именно поэтому считается, что MFT-файл не подвержен фрагментации. Но если на диске хранится большое количество мелких файлов, то размера MFT в какой-то момент начинает не хватать. Он растет, подхватывая фрагментированные куски свободного пространства. То же самое происходит и при заполнении диска более чем на 90% — остаток зарезервированной области усекается, выделяясь в общий пул свободного пространства. Обратно в MFT уже не возвращается, и потому его фрагментация неизбежна, если, конечно, не позаботиться о решении проблемы заранее. Например, можно просто создать в цикле огромное количество файлов нулевой длины. Точное количество зависит от размера структуры FILE_RECORD в MFT (она переменчива), но для наших целей вполне подойдет и упрощенная формула: N_FILEZ = DISK_SIZE/2, где размер тома выражен в килобайтах. Удаляем все файлы кроме двух-трех, созданных последними. Как нетрудно догадаться, они будут располагаться в самом конце MFT, жестко фиксируя его нижний размер (что предотвратит высвобождение MFT-области в общий пул).

 

надо срочно тулзу, которая сможет дефрагментировать мфт и кильнуть незаюзанную дрянь в конце, вернув 10% на место

 

да, нужен нормальный дефрагментатор... или лучше сразу новую fs?))

 

reiserfs?

 

Вроде по умолчанию под MFT резервируется 1/8 или 12.5%

 

Может в 3.1 и 3.0 разный обьем?

 

Дефрагментировать МФТ как файл умеет практически любой бут-тайм дефрагментатор. А вот дефрагментировать содержимое МФТ - нет таких тулзов. Если в конце МФТ гарантировано нет занятых записей то можно попробовать руками уменьшить размер. Но это будет непросто - нужно будет обновить битмап, индексы и т.д. Проще отформатировать.

 

А на виртуальной машине эти файлы так и остануться внутри?

 

bobov
в смысле?