FAT32 vs NTFS: что лучше и стоит ли переходить?

[CaptainFlint]

Vampir:
По умолчанию Windows XP резервирует 12,5% от объема каждого NTFS-раздела для «зоны MFT»

Вот именно, что для "зоны MFT", а не для самого файла MFT. Файл MFT занимает ровно столько, сколько требуется - по количеству файлов на диске. Зона MFT - это лишь свободное место, никак не используемое, пока есть такая возможность. Разумеется, корреляция есть: больше раздел - больше файлов - больше размер MFT-таблицы. Но сама NTFS построена так, что это увеличение практически не влияет на её производительность, разница составит доли процента, которые даже в тестах не будут замечены - погрешности больше - не говоря уж о реальной работе.

Опять же слетит весь диск или только один раздел

NTFS достаточно надёжная система, чтобы не слетать просто так. Если она слетает - значит, есть тому физические причины. А это значит, что абсолютно пофигу, сколько у тебя там разделов: когда накрывается винт, накрываются все разделы. Кстати, когда слетает таблица разделов, восстановить один раздел несравненно проще... Это так, кстати.

dimonk:
во, точно. все дело в том, что мфт у нее может находиться в любом месте раздела и от тряски лишь немного двигается туда-сюда. тогда как у фат32 две копии фат стукаются дружка о дружку и возможна потеря данных.

[dimonk]

CaptainFlint:
Вот именно, что для "зоны MFT", а не для самого файла MFT. Файл MFT занимает ровно столько, сколько требуется - по количеству файлов на диске. Зона MFT - это лишь свободное место, никак не используемое, пока есть такая возможность. Разумеется, корреляция есть: больше раздел - больше файлов - больше размер MFT-таблицы. Но сама NTFS построена так, что это увеличение практически не влияет на её производительность, разница составит доли процента, которые даже в тестах не будут замечены - погрешности больше - не говоря уж о реальной работе.

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

CaptainFlint:
NTFS достаточно надёжная система, чтобы не слетать просто так

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

[CaptainFlint]

dimonk:
с небольшой поправочкой, что фрагментация мфт - не очень приятная штука и на производительность все-таки влияет не очень положительно

Ну это-то ясно, фрагментация, как я уже говорил - всё же отдельный вопрос.

Кстати, прочитал я статейку, ссылку на которую дал Vampir на прошлой странице. М-дя... Потрясающий сборник маразмов. Особенно это понравилось:

2. Называйте файлы соответственно
<...> В таком случае можно улучшить производительность NTFS, выбрав более подходящую схему именования файлов — при этом различия в похожих названиях файлов должны находиться ближе к началу названия. К примеру, вместо названий типа "Улучшение производительности NTFS часть 1.doc" лучше называть файлы вот так: "1 часть — Улучшение производительности NTFS.doc". В таком случае NTFS не придется долго думать над присваиванием уникального 8.3-имени каждому файлу в папке.

Просто потрясающе! Чтобы NTFS думала над чем-то - это сколько надо выпить, чтоб такое написать! "Думает"-то процессор! А короткие имена составляются настолько элементарным алгоритмом, что думать там абсолютно не над чем - просто берётся начало файла (с заменой некорректных символов корректными), дописывается тильда и порядковый номер. Поэтому даже если файлов с одинаковым началом имени будет хоть тысяча штук (не верю, что хоть где-то такое есть), перебрать тысячу чисел для процессора - это микросекунды!
Ну и остальное в том же духе...

[dimonk]

CaptainFlint
это тебе так кажется, что все просто: ты логически выделяешь смысл названия файла и понять, что оно означает, для тебя не составляет труда. а вот файловой системе, действительно, надо сначала покряхтеть, подумать... лично я файлы нумерую. каждый новый файл называю так: делаю в тотал коммандере ctrl-b в корне диска с сортировкой по имени, нахожу последнее в списке имя файла и добавляю к нему единичку. это ничего, что потом трудно ориентироваться, зато системе приятно. к тому же, наиболее часто испольуемые номера файлов запоминаются. в результате что имеем? на моем домашнем p4-2800/1024/120gb sata + 120 gb pata я не чувствую тормозов, которые присущи нтфс.

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

[Vampir]

фат12 и фат16

давно понравилась FAT-16
у меня винт лежит рабочий на _20_Mb отфрагментированный в NU-dos им, как Nokia3310 можно орехи колоть и ничего не будет

действительно, можно опт-вать дисковую подсистему

Нужно. Залог надежности. у самого ХР-юша с 2003, более 500 прог установлено, как по маслу, брату размечал в 2002г. тоже работает PC каждый день.

в тотал коммандере ctrl-b

хорошая команда, оценил.

схемой именования файлов

это полезно для БД где 10тыс файлов в одной папке, имхо.

ps: Может новую ветку открыть ? по новым ФС ? уже все разжевали...

[dimonk]

Vampir:
это полезно для БД где 10тыс файлов в одной папке, имхо

это где ты такую бд видел, интересно?

[dimonk]

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

Vampir:
ps: Может новую ветку открыть ? по новым ФС ? уже все разжевали

угу. только сразу в разделе "флейм". winfs толком никто не видел (или мало кто видел), всякие ext2/ext3/raiser/hpfs и т.п. давно не новые. что будем обсуждать-то?

[Vampir]

Windows Future Storage (WinFS)

[crawler]

WinFS вообще не является физической ФС, а надстройка над NTFS с возможностями БД. Так что доступ к конкретному файлу не измениться, но поиск будет организован лучше.

ИМХО гонять SQL сервер ради гипотетичекой необходимости поиска внутри файлов - для домашнего юзера -бред.