2 schuss:
А это и не особо нужно, да и бывает очень редко по двум причинам: если диск забивается большими файлами, то их мало и MFT практически не растет, а следовательно не фрагментируется...
Ошибка:
таблица размещения не может не расти. Нам нужно хранить указатель на КАЖДЫЙ используемый кластер. Для любой файлухи произвольного доступа. Это не ISO9660. :)

Если файлы слишком мелкие - несколько сотен байт, то они вообще хранятся в структуре MFT, не занимая отдельного кластера, так что при этом еще и место на диске экономится.
Да, для них кластер не используется.
Возьмем стандартную ситуацию, когда файлы идут вперемежку.
Я посмотрел свой системный раздел. 32Гб, помойка забитая полностью всяким хламом.
35000 файлов размером менее 1к. Экономия места при хранении в МФТ была-бы 140Мб при размере кластера 4к. Менее 1%.

Если мне не изменяет склероз, fdisk и format из комплекта Windows9x при разделе больше 32 гигабайт делают кластер 32 килобайта,...Теперь берем кластер размером 4 килобайта и получаем на том же разделе 33554432 кластера, так что одна таблица займет уже 134217728 байт или 128 мегабайт, а с копией, соответственно, 256 мегабайт. Представляешь, с какой скоростью будет идти поиск по такой таблице в случае мало-мальской фрагментации, да и мне лично, к примеру, просто жалко тратить столько места впустую...
Ошибка:
Поиск по копии не ведется. При любом раскладе, если "жалко" терять место под таблицу, то нужно увеличивать размер кластера. Тогда теряешь на хвостах файлов (пример реального случая я привел). Пока раздел не забит полностью, места зарезервированного по ФАТы жалко быть не может (есть же свободное).
Возьмем "стандартный" размер кластера 32к со всеми вытекающими (у меня в примере это именно так). Размер таблицы для поиска по разделу - 16мб. Вполне влезет в кэш. Независимо от сегментированности.

Теперь возьмем NTFS. Количество записей MFT зависит от пикового количества файлов и каталогов на диске и не зависит от размера кластера, а все незанятое место может использоваться под файлы.
Ошибка:
Я уже говорил, что так или иначе нам следует хранить информацию о КАЖДОМ занятом кластере. Таким образом, суммарный размер таблицы размещения не может быть меньше чем количество кластеров на диске. Экономия- только на маленьких файлах (менее 1%). Чем меньше размер кластера тем больше ссылок на занятые кластера мы должны хранить в МФТ (даже если список занятых файлом кластеров лежит в отдельном от МФТ кластере, мы все равно должны затратить на него место, и эта информация- критична для файловой системы; по-этому отделять ее от МФТ нельзя, по крайней мере я в своих рассуждениях их объединяю, пусть звучит слегка безграмотно, зато правильно, понятно и писать коротко :)).

Так что, МФТ не может быть меньше ФАТ при одинаковм размере кластера. ФАТ теряет место ТОЛЬКО на маленьких файлах (менее 1%) и на второй копии ФАТ (опять менее 1%). При этом ВСЯ информация о размещении КАЖДОГО файла у нас сдублирована.


Обычный размер одной записи MFT - 1 килобайт. Возьмем для пикового количества файлов и каталогов не очень реальное число 100000 - получим размер MFT меньше ста мегабайт. При этом не забываем, что каталоги и мелкие файлы часто целиком умещаются в структуре MFT ине требуют под себя отдельного кластера, как в FAT.
На моем системном 32Гб разделе 190 000 файлов, из них 35 000 менее 1кб.
Таким образом, размер МФТ не может быть менее 200 Мб.
А теперь твой вопрос: как вести поиск по ТАКОЙ таблице?! Уж в кэш-то она точно влезть не должна. На моем разделе кластер - 32к. 4Мб ФАТ в кэш влезет при любом раскладе. (после такого начинаешь понимать, почему ХП высвапливает активные приложения для того, чтобы вспусить кэш до 80% от размера оперативной памяти... Гы-гы)

По поводу этой файлухи: Дефрагментатор не запускался ни разу. Тем не менее, ФАТы выглядят вполне прилично (могу прислать :)). Потери, конечно, гигантские- около 5Гб. Но, если учесть, сколько там дерьма (уж не менее 10Гб, это точно), то это мелочь.

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


В таких условиях фрагментация MFT возникает достаточно редко (я лично на своих дисках ее ни разу не наблюдал).
Скорее всего, это потому, что винда просто врет, о том, что фрагметрировано а что нет.
Или ни разу диск не забивался на 100%. Тем не менее, большинство пользователей видят на своих компах надпись как "low disk space" (что по-русски означает "если у вас НТФС прекращайте писать на диск НЕМЕДЛЕННО, а то я за себя не ручаюсь") так и "out of disk space" (что по-русски означает "если у вас НТФС, лучше отформатируйте раздел, а то это полная жопа а не файлуха, и я ничо с этим делать не буду- звоните Нортону")

К тому же, если мне не изменяет склероз, упоминавшийся здесь нортоновский спиддиск умеет дефрагментировать и MFT. Впрочем, дефрагментация NTFS-томам требуется гораздо реже, да и фрагментация влияет на быстродействие NTFS намного меньше, чем на быстродействие FAT.
Все в точности наоборот. :)
ФАТ менее подвержен фрагментации, всилу своей тупости. При любом раскладе (при любом драйвере ФС) можно быть увереным в одном: следующий кластер лежит дальше предыдущего. Файл не вальсирует по диску как в случае с НТФС.

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


И как я уже говорил, вытаскивать в случае серьезного краха данные с фрагментированной NTFS легче, чем с фрагментированной FAT...
Это почему? Потому что в НТФС не только не знаешь, где лежат данные, но и не знаешь, где лежит даже таблица их размещения? :)


А уж как весело вытаскивать данные, если была убита таблица разделов, а шибко грамотный юзверь запустл fdisk, я уже писал... А ведь без запуска fdisk'а на восстановление таблицы разделов ушло бы минут 10-15. Юзверю же, сидящему на NTFS, и в голову не придет запускать fdisk, так как он либо знает, что fdisk c NTFS работать не умеет, либо вообще не знает, что такое fdisk.
А зачем фдиск должен уметь работать с NTFS? Тип файлухи проставить?
Все-таки интересно, как fdisk заставить сделать такое...

Смотри упоминавшуюся мной ссылку - размер одной записи MFT редко бывает больше килобайта.
В 1к можно запихнуть максимум 256 индексов. При 4к на кластер- это файл размером всего 1Мб.

Второй раздел (а лучше второй винчестер) для бэкапа нужно иметь в любом случае. А еще лучше вообще не держать на системном разделе важных данных, так как системный раздел летит чаще вне зависимости от того, какая на нем файловая система.
Вот с этим я как раз не спорю: всякую ерунду (ОС, программы) - на системном (можно и НТФС). А для важных данных- ФАТ. Их, как правило, не так много. :)
Диверсии со стороны других пользователей компа- это разговор отдельный, и к нашим винтам отношения не имеет.
Главная мораль (если нас кто-нибудь читает): ни в коем случае не делать один раздел на весь винт.

В том-то и дело, что NTFS-раздел с бэдами в MFT система без особых заморочек сама прочитает, за исключением файлов, чьи записи попали на битые секторы, а FAT в таких случаях читается далеко не всегда - регулярно наблюдал, как в такой ситуации попытка считать файлы просто отваливалась с сообщением типа "диск не отформатирован" при попадании первого же файла, ссылка на кластеры которого лежит в поврежденном секторе. В результате копирование уцелевших файлов с FAT превращается в мучительный процесс.
Это только слишком глючная программа может сказать. Например, виндоуз ХП :). Копирование с битых ФАТ процесс, конечно мучительный, но не надо этого делать средствами ХП. :)

Сообщение от deCore
Это смотря что сдохло. Вот сдохла таблица размещения этого самого МФТ. Чо делать? В случае ФАТа пусть дохнет что угодно, но если данные о размещении КОНКРЕТНОГО файла есть (ну и данные файла тоже), то его легко можно вытащить.
------------
Именно для этого 16 записей со ссылками на метафайлы, включая MFT, дублируются в центре диска, так что опять мимо тазика.
Опять ошибка:
Даже если там хранится таблица размещения этого самого МФТ, то в 16 записях по 1к можно сохранить информацию о размещении файла размером 16Мб максимум (при 4к на кластер). Размер же МФТ, как я уже приводил пример с 32х Гб разделом будет не менее 200Мб. Так что, мимо тазика. :)

В случае NTFS может сдохнуть все, кроме записи MFT про этот конкретный файл (и данных этого файла, естественно), и этот конкретный файл тоже можно будет вытащить.
Соответственно, до записи в МФТ добраться будет просто невозможно. Речи о размещении конкретного файла даже быть не может. :)

А с NTFS это не нужно делать, так как все копируется стандартными средствами, за исключением непосредственно пострадавших файлов...
Ну, слишком легкие случаи, видимо, были. Так не интересно. :)
(ЗЫ: пока на сбойные кластеры в ФАТах не наступать, разумеется и с ФАТов можно скопировать усе).

Цитата:
Сообщение от deCore
"Стремительно терять популярность" это значит что мысль об отказе от него для некоторых перестала быть бредом?
Это значит, что люди стали от него отказываться...
Вот с этим я согласен. Но вовсе не в массовом порядке.