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

[schuss]

2 schuss:
нужно хранить указатель на КАЖДЫЙ используемый кластер.

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

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

В FAT32 размером 32Г кластер 16к (а то и 32), потери только на мелких файлах 35000х15к = 525000к. В NTFS на эти файлы ушло бы около 40М. В 96 году вышла Win95 OSR2 c FAT32, и чтобы обосновать переход с FAT16 на FAT32 для тех, кто кричал "FAT32 бяка: тормознее и не видно из DOS 6.22", собрал статистику и выяснил, что при достаточно большом числе файлов разного размера потери в среднем на один файл теряется половина кластера. 190000 х 8к = 3040000к или полтора гига потеряного места.
А хранение мелких файлов в MFT - это уменьшение фрагментации (при удалении файла не появляется дыра в один кластер) и увеличение скорости доступа к этим мелким файлам.

если "жалко" терять место под таблицу, то нужно увеличивать размер кластера.

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

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

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

Я проверил у себя. Раздел 33000 мегабайт (то есть чуть больше 32 Г). Форматировал его по очереди в FAT32 с кластером 32к и с минимально возможным кластером 8к (меньше не дала сделать ни одна форматилка, format.com из винды 9х вообще соглашался минимум на 16к), NTFS с кластером 32к и 4к.
На диск копировался один и тот же набор файлов общим размером 33160769233 байт. Мелких файлов там, правда, не очень много, т.к. это диск с архивами, фильмами, музыкой и играми.
Вот информация chkdsk:

FAT32 кластер 32

33784416 КБ всего на диске
51872 КБ в 1619 папках
33123072 КБ в 30484 файлах
609 440 КБ доступно

32768 байт в каждом кластере
Всего кластеров на диске 1055763

FAT32 кластером 8

33759704 КБ всего на диске.
48 КБ в 6 скрытых файлах
13536 КБ в 1620 папках.
32537872 КБ в 30484 файлах.
1208240 КБ доступно.

8192 байт в каждом кластере.
Всего кластеров на диске: 4219963.

NTFS кластер 32

33792695 КБ всего на диске.
32961472 КБ в 30485 файлах.
37472 КБ в 1627 индексах.
0 КБ в поврежденных секторах.
98423 КБ используется системой.
65 536 КБ занято под файл журнала.
695 328 КБ свободно на диске.

Размер кластера 32768 байт.
Всего кластеров на диске 1056021.

NTFS кластер 4к

33792695 КБ всего на диске.
32437152 КБ в 30485 файлах.
9944 КБ в 1627 индексах.
0 КБ в поврежденных секторах.
99123 КБ используется системой.
65536 КБ занято под файл журнала.
1246476 КБ свободно на диске.

Размер кластера 4096 байт.
Всего кластеров на диске 8448173.

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

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

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

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

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

Вытаскивать данные с нефрагментированной файлухи с ФАТ легче хотя-бы потому, что все они лежат где положено, а не где попало.

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

Если файлы большие, то пофиг, если инфа об их размещении потеряна полностью.

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

Потому что в НТФС не только не знаешь, где лежат данные, но и не знаешь, где лежит даже таблица их размещения?

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

Все-таки интересно, как fdisk заставить сделать такое...

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

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

Смотри выше.

всякую ерунду - на системном. А для важных данных- ФАТ.

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

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

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

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

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

Ну, слишком легкие случаи, видимо, были. Так не интересно.

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

Вот с этим я согласен. Но вовсе не в массовом порядке.

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