[rover_61eg]

1024 мбайта, не?

[AMDBulldozer]

Balancer, какой бы размер кластера у Вас ни был, объем данных, занимаемых файлом любого размера будет равен размеру файла с округлением до размера кластера в бОльшую сторону. То есть, если кластер равен 4096 байт, то любой файл размером 1-4096 байт займет 1 кластер (4096 байт). А файл размером 4097 байт займет два кластера - 8192 байта.
Правда, необходимо учитывать, что кроме данных файловая система содержит также метаданные - данные о расположении, названии, времени создания/доступа/модификации, атрибутах и т.д. файла (конкретный список зависит от типа файловой системы).
Понятно, что при большем размере кластера, файлы одного и того же размера занимают меньшее количество кластеров, поэтому накладные расходы на хранение метаданных обычно уменьшаются.

[Balancer]

Спасибо, понятно.

А если у меня кластер 1мб, то 500 файлов по 1кб будут весить 500 мб я правильно понял?

[AMDBulldozer]

если у меня кластер 1мб, то 500 файлов по 1кб будут весить 500 мб я правильно понял? »

Честно признаться, именно этот момент я намеренно опустил в своём предыдущем сообщении. На самом деле, некоторые файловые системы (в том числе, насколько мне известно, NTFS) поддерживают "упаковку хвостов"). То есть, если имеется большое количество мелких файлов, эти системы могут паковать их по несколько штук в один кластер. Либо, упаковать туда "хвост" файла - ту его часть, которая должна была бы не полностью занять последний кластер.
Поскольку поддержка такой возможности в некоторых ФС не реализована вообще (FAT), а в других реализована совершенно по-разному (Reiserfs, NTFS), то, не зная типа файловой системы, невозможно предсказать какой объем дискового пространства займут файлы в Вашем случае.

P.S. Вообще, если персонально Вы не занимаетесь разработкой драйверов файловых систем, разумнее всего не рассчитывать на то, что ФС за Вас упакует несколько файлов в один кластер. Пользоваться такими большими кластерами особого смысла нет (скорость ввода вывода они Вам не только существенно не увеличат, но, как мы увидим далее, могут даже уменьшить). Кстати, у всех известных мне ФС предельный размер кластера строго ограничен. ФС ext2/3/4 имеют фиксированную величину блока 1, 2 или 4кБ (термин "блок" для файловых систем Unix имеет то же значение, что термин "кластер" для MS-DOS/Windows). Максмальный размер блока для Reiserfs - 8 кБ, UFS - 32кБ, XFS и NTFS - 64 кБ, JFS и ZFS - 128 кБ. Мегабайтные блоки не поддерживает ни одна из известных мне ФС (может быть какая-то и позволяет их создавать, но мне она неизвестна). Не поддерживает именно потому, что, по мнению разработчиков, они не нужны.
Но, если, по каким-то причинам, уже возникла ситуация, когда Вам необходимо хранить много маленьких файлов в ФС с огромными кластерами, сами организуйте их в архивы размером в несколько кластеров (можно без сжатия).
Вы скажете, что это повлияет на скорость выполнения файловых операций? Так "упаковка хвостов" на них влияет точно так же.

[Balancer]

Большое спасибо за помощь, но у меня ещё один вопрос: Жёсткий диск в 700Гб я собираюсь разбить на 2 раздела - 1ый для ОС и программ (100 ГБ), 2ой для всего остального (сериалы, игры, и т.д.). Какой оптимальный размер кластера стоит установить для 1ого раздела и какой посоветуете для 2ого?

[Ment69]

Balancer, Если я правильно понял AMDBulldozer, в вашем случае забивать себе голову размерами кластера не стоит, ничего от их изменения вы не получите!

[fd4tvk]

Какой оптимальный размер кластера стоит установить »

4 Kb

[yurfed]

ничего от их изменения вы не получите! »

Немного не так.
Допустим имеем базу из файликов около 4 КБ, тогда оптимальным будет ставить размер сектора именно 4 КБ, если база имеет размер в среднем 512Кб, то естественно и размер кластера, должен соответствовать размерам файлов.
В этих примерах скорость и распределение диска будут самыми оптимальными.
Однако в действительности, всё далеко не так, и в настоящей жизни, мы имеем самый разнообразный софт, с самым разным размером файлов. Поэтому забивать себе голову размером сектора не стОит, если не имеются из ряда вон конкретные задачи.

"упаковка хвостов" »

Какая упаковка, какие хвосты? Если в FC записан какой то байт, значит сектор занят и ни какие действия с ним дальше не производятся.
Может я не правильно понял и имелось ввиду сжатие томов?

ЗЫ Всем остальным - не морочить себе голову и форматировать как предлагает система.

[minos66]

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

А вы не скромничайте. Дайте ссылочки где про это почитать. Но насколько мне известно NTFS такими извращениями не занимается... честно говоря, лично я уверен, что это

То есть, если имеется большое количество мелких файлов, эти системы могут паковать их по несколько штук в один кластер. Либо, упаковать туда "хвост" файла »

или неправильно истолковано, или какая то побасенка

если имеется большое количество мелких файлов, »

Если размер файла не превышает размер записи в $MFT (~1 Кб), то он в MFT и хранится. Почитайте про резидентные файлы NTFS.

Какой оптимальный размер кластера »

Присоединяюсь к yurfed, fd4tvk, Ment69 - По выбору системы (в NTFS это 4Kб)....