Идеальная работа операционки, чем лучше пользоваться ?

[deCore]

А откуды ты знаешь, что в NTFS кластеры адресуются также, как в FAT? Для файла в 7 гигабайт (iso-имидж DVD) запись в MFT занимала 2 сектора, то есть 1024 байта - я проверил...

Это всего-лишь означает, что там реально хранится не таблица размещения файла, а ссылки на кластера где эта таблица хранится на самом деле. Это- обычный подход на файлухах с и-нодом (чем, фактически, является запись в МФТ). Это означает, что таблица размещения одного файла гуляет по всему диску (по крайней мере, по всей МФТ).

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

Долго думал? :) (без обид, тем более если кого-то в этом приходилось даже убеждать...гм...)

А хранение мелких файлов в MFT - это уменьшение фрагментации (при удалении файла не появляется дыра в один кластер) и увеличение скорости доступа к этим мелким файлам.

Скорости чтения мелких файлов. Прикинь, что будет, если этот мелкий файл будет расти... Сначала его запихнут в МФТ, потом перенесут в кластер...

В том-то и дело, что в NTFS размер MFT не имеет жесткой связи с размером кластера.

Просто это означает, что настоящую таблицу размещения не причисляют к МФТ. Но это не означает, что ее не нужно хранить.

Только вот в FAT для поиска по диску надо облазить не только таблицу, но и каталоги, размазанные по всей занятой поверхности диска.
А в NTFS поиск ведется практически только по файлу MFT, то есть в пределах одной небольшой зоны в начале диска.

Ты имеешь в виду поиск файла по имени? Хочешь сказать, там имя файла лежит в МФТ? Это означает, что хардлинк имеет отдельную запись в МФТ? "Ужас-ужас!" (С) анекдот. %) НЕ ВЕРЮ! (С) другой мужик.

У меня предложение: создай на каком-нибудь винчестере раздел такого же размера, как твой системный раздел, отформатируй его в NTFS, скопируй на него всю эту свою помойку подчистую и сравни оставшееся свободное место со свободным местом на FATе.

Ну, могу, в принципе (хотя винта второго у меня нет): но результат и так ясен: при том же размере кластера (32к) поимею экономию на 35 000 мелких файлах порядка 1Гб.

Я проверил у себя. Раздел 33000 мегабайт (то есть чуть больше 32 Г).
...

Интересные цифири. Видно, что 70% каталогов хранится в кластерах.
Средний размер каталога- 6к

Итого в моем случае свободного места на NTFS со стандартным кластером осталось вдвое больше, чем на FAT32 со стандартным кластером. При этом на NTFS свободно больше 3%, а все служебные файлы, включая MFT, занимают меньше 200 мегабайт, то есть MFT практически гарантированно находится в своей зоне и нефрагментирована.

Она нефрагментирована, т.к. с нее ничего не удалялось. :) Не важно, на 97% или на 100% она при этом забита.

Видимо, мы общаемся с разными пользователями. :) На большом разделе в FAT "out of disk space" может появиться раньше, чем "low disk space" на таком же в NTFS, из-за малых потерь на хвосты кластеров и на мелкие файлы. Стандартный кластер для FAT32 разделов от 8 до 16 гигабайт - 8к, от 16 до 32 гигабайт - 16к, выше 32 гигабайт - 32к.

Ну, сравнивать потери на хвосты при 4х к/кластер и 32к/кластер заведомо некорректно. Вон, посмотри, на сколько отличается 8к ФАТ и 4к НТФС в твоем примере.
Да и не важно, когда будет надпись "low disk space". Она будет- этого достаточно. А за ней и "out of disk space"...

Если размер файла заранее известен (например, файл копируется с другого носителя), то драйвер NTFS найдет для него такой кусок свободного места, в котором данный файл поместится целиком.

Возможно, драйвер ФАТ поступит также. Правда, не знаю какой именно. :)

Если же такого нет, то сначала будет заполнен самый большой кусок, потом кусок поменьше и т.д.

Ты, наверное, сам не читал статью по своей ссылке? :)

А тупой FAT будет заполнять все участки подряд. То есть в случае одинаковой фрагментации диска, у которого, к примеру, ближе к началу диска располагается множество мелких кусочков свободного места, а в конце несколько больших кусков, на FAT файл будет разбит на большое количество мелких фрагментов, а на NTFS на меньшее количество более крупных и даже если они "вальсируют" по диску - скорость доступа к этому файлу будет выше, так как головам все равно делать меньше движений.

Можно, конечно, представить такую ситуацию. Но чаще будет наоборот :)

С нефрагментированной NTFS ситуация аналогичная.

Да нет же. Сам в начале говорил, что запись 7Гб файла в МФТ занимает 1к. А ГДЕ САМА ТАБЛИЦА-то? Ответ: хрен знает где (но где-то она точно есть, иначе этот файл нельзя прочесть будет :))

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

Ты все-таки подумай, где хранится сама таблица размещения МФТ? Если похерится сектор в ней, то мы имеем полностью недоступную файлуху.

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

Хочешь сказать, что имя файла дублируется в МФТ и в директории? Ничего похожего на имя файла я в МФТ не вижу. :)

В смысле, как заставить забить сектора мусором?

Да.

Большинство легких случаев типа зависания системы или отрубания питания в неподходящий момент, вызывающих при FAT'е повреждения, требующие обращения к спецу, на NTFS не влияют никак - после рестарта она по журналу либо закончит транзакцию, либо откатится в предшествующее состояние, так что структура файловой системы останется неповрежденной, а пользователь потеряет только те данные, которые не успел сохранить.

Журнал рулит, однозначно. Но файл, записаный во время незакрытой транзакции все равно будет потерян.

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

Да ничем не чревато. Любой скандиск это отловит и сдублирует эти файлы. Какой из двух файлов оставить- на выбор пользователя (косячный файл отлавливается легко). Если в директории осталась запись только на поврежденный файл, это (автоматически) означает, что файл был удален, значит он все равно не нужен. А потеряться сможет только тот файл, который был недавно (меньше одного флаша назад) записан. Т.е. ситуевина, аналогичная незакрытой транзакции.
Глянул, кстати, у себя на "потеряные" файлы - четыре штуки за 2 года. Все- из temp.

В DOS'е ситуация аналогичная - либо просто подвисает, либо отваливается с воплем, что диск не отформатирован.

Подвисает- помню. Правда, не насмерть. Просто тормозит долго.

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

А фиксированного смещения нет и в NTFS. Или мне не по шарам? Скажи, тогда, какое.

В NTFS легкие случаи обычно легче чем в FAT и восстанавливаются средствами самой системы, так что юзер их просто не замечает, а тяжелые бывают намного реже, чем в FAT, правда, они и намного тяжелее.

Я думаю, что ты путаешь проблемы ФАТ и проблемы виндов 9х. XP вполне надежно ведет себя на ФАТе. Проблем пока не встречал.

В достаточно массовом порядке, особенно если учесть, что многие работавшие под Windows 9x уже не подозревали, что там есть DOS... :D

Ну я в самом начале и сказал, что они его имеют независимо от того знают об этом или нет. :)