Бакуленко МаксВопрос, понятно, едва ли имеющий решение.Вопрос, не требующий решения. Проблемы - не существует.

Бакуленко Макссмешно же, имея кучу свободного места получить на выходе фрагментированный файл.Почему? Если получение фрагментированной MFT действительно катастрофично, то фрагментация файла, особенно большого, вряд ли зло. А иногда даже благо.

Бакуленко Макспишется в середину диска, и присутствует легкая фрагментацияПочему в середину, понятно? ближе к MFT, головам меньше мотаться.
А фрагментация есть результат кэширования. Попробуйте выполнить эксперимент дважды - один раз с кэшированием записи, второй без...

Бакуленко МаксЕсть вообще в злооси (Windows 2003 Server) параметр реестра, отвечающий за поиск места перед записью?Конечно, нет. А не нравится ось - используйте линукс.

Ха-Ха Ха-ХаГде-то когда-то читал, что винда умышленно старается затереть кластеры, бывшие под файлами. Типа для пущей безопасности - гарантии физического удаления файлов.
Забудьте поскорее эту ахинею.

Алексей (Витебск)

автор this is generally only for database servers, and should be used with great caution as it can cause servers with heavy small file traffic to quickly fill disks. On the positive side, it significantly reduces fragmentation of data files by forcing larger contiguous allocations.

Я бы перевёл это так - лучше не лезть, куда не просят...

Бакуленко МаксПравда, некий Крис Касперски советовал выделять побольше места под MFT, намекая, что по умолчанию 12.5% это маловато, и как только раз количество файлов приведет к переливу MFT за отведенный участок, всё, кирдык, дальше производительность будет только падать.
Похоже, Вы ничего не поняли.

12% (именно 12%, а не 12.5%) изначально, при форматировании, занимается (вернее, резервируется) под MFT. И в 99% случаев это - с избытком. С ба-а-альшим избытком. Чтобы нехватило, надо забить весь том файлами размером более 1.5к, но менее 4к. В реальных условиях такого не бывает.
Тормоза возникают по совсем обратной причине - когда файлы занимают более 88% тома, начинается использование резервированного под MFT пространства. Это приводит к фрагментации MFT, причём чем меньше на томе свободного места и чем интенсивнее файлообмен, тем быстрее и сильнее эта фрагментация. Которая, кстати, штатными средствами не устраняется.
Именно фрагментация MFT и приводит к катастрофическому падению производительности тома. Даже после того, как на нём освобождено достаточно места.

Бакуленко МаксИ что же я не так понял, сказав, что со слов Касперски под MFT надо резервировать больше места при создании тома?Давайте ссылку на оригинал - вот тогда и разберёмся, что не так понято.

Бакуленко Макс

Он пишет в точности то же, что и я.

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

Ну что ждать от WinFS - это ещё ба-а-альшой вопрос.

Странно, что практически нет ни отзывов, ни исследований по ExFAT... MS походу или что-то скрывает, или ошиблась с маркетингом.

Не только MFM, но и все ST-506, а также подавляющее большинство ESDI требовали для максимальной производительности подбора фактора чередования.