» Размер кластера

объяните темному чем малый кластер (512к) плох на большом диске? скорость падет? сильно ли?

Я свой диск разбил на разделы по 10, 20 Гб. А размер кластера оставил стандартным. Хотелось бы тоже услышать и по этому поводу мнения.

roman78
Таблица размещения файлов становится большой. Из-за этого, наверное, и скорость может упасть.

скорость однозначно упадет. насколько - сам хотел бы знать. цитата из PartitionMagic online help: 4K clusters will enable you to regain lost performance caused by potentially inefficient 512-byte clusters там же можно посмотреть для своего диска потери на кластеризацию для всех возможных размеров кластера (Partition | Advanced | Resize custers...) лично я не экспериментировал, всегда 4к по умолчанию. уменьшать - дурь имхо: ну на 1% больше места станет, смысл? если уж и крутить, то в сторону увеличения, впрочем, и это наверное тоже дурь: вряд ли что-то сильно изменится. кто знает - отзовитесь!

во-первых извиняйте за очепятки - кластера в 512к я не видывал, речь конечно о 512 байтах

VdV
логично...

Almaz
4к вполне устраивает. Просто я думал по умолчанию будут те же кластера что и на FAT'e, вот и решил посоветоваться. Ну да, у меня до сих пор 2 диска в фате - если PM там чего покоцает... вобщем боюсь его подпускать.
А если 4к стандарт независимо от размера диска, то возможно поэтому NTFS проигрывает FAT'y на дисковых операциях (ессно после дефрагментации дело было ). Точных цифр (и подробностей) не помню, что-то около 10%, кому интересно где-то на ixbt тесты были.

Для FAT32 размер кластера влияет на максимальный объема раздела т.е.
4 kb - 8 Gb
8 kb - 16 GB
и т.д.
Все потому что количество кластеров ограничено.
P.S. Меньше 4 kb на кластер почему-то не рекомендуется.

Tак никто чёткого ответа и не дал. Так какое отношение размера кластера к размеру раздела является оптимальным для ФАТ и НТФС

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

roman78
NTFS5:
работаешь с видео? втыкай хоть 64Kb - будет быстрее (в теории - на практике разница приведет к погрешности при вычислениях)
если много мелких файлов (до 80мб) то 4Kb твой выбор

Цитата:

какое отношение размера кластера к размеру раздела является оптимальным?

Цитата:

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

Demetrio
Я конечно понимаю, что это ты просто "зарапортовался", но всё равно интересный ответ получился. Спасибо.

rater2
Если много мелких файлов и хочешь сэкономить на месте тогда ставь поменьше
Для монтажа делай как Farch говорит

вот для развития
цитата с WinXP FAQ (v3.05)

Цитата:

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

Размер раздела Секторов в кластере Размер кластера
< 512mб 1 512 байт
< 1024mб 2 1K
< 2048mб 4 2K
< 4096mб 8 4K
< 8192mб 16 8K
< 16384mб 32 16K
< 32768mб 64 32K
> 32768 MБ 128 64K

Небольшое исключение для системного раздела: если он меньше 2048МБ, то размер кластера, при использовании NTFS, всегда 512 байт.
Кроме этого, при конвертации Fat32 раздела в NTFS встроенной в XP утилиткой convert, размер кластера всегда будет 512 байт. Что бы избежать, придётся воспользоваться внешними программами, например Partition Magic.

rater2
Ну, опечатался
Вот тебе ещё ссылка:
http://www.ixbt.com/storage/ntfs3.html

Demetrioспасибо за ссылку. рискну процитировать здесь кусочек: для меня стало открытием, что за кластер >4k пришлось бы платить так дорого (для меня лично)

Цитата:

Типичный размер кластера для NTFS - 4 Кбайта. Стоит отметить, что при большем размере кластера отключается встроенная в файловую систему возможность сжатия индивидуальных файлов, а также перестает работать стандартный API дефрагментации - т.е. подавляющее число дефрагментаторов, в том числе встроенный в Windows 2000, будут неспособны дефрагментировать этот диск. SpeedDisk, впрочем, сможет - он работает без использования данного API. Оптимальным с точки зрения быстродействия, по крайней мере, для средних и больших файлов, считается (самой Microsoft) размер 16 Кбайт. Увеличивать размер далее неразумно из-за слишком больших расходов на неэффективность хранения данных и из-за мизерного дальнейшего увеличения быстродействия. Если вы хотите повысить быстродействие NTFS ценой потери возможности сжатия - задумайтесь о форматировании диска с размером кластера, большим чем 4 Кбайта. Но имейте в виду, что это даст довольно скромный прирост быстродействия, который часто не стоит даже уменьшения эффективности размещения файлов на диске

Если посмотреть тесты зависимости скорости от размера кластера, видно что до 8-16 kb скорость растет заметно а потом почти не растет.

Almaz

про сжатие все верно, но вот у меня на 64 кбайтном кластере вроде дефрагментация идет стандартными средствами XP. Или это только в 2000 не работает?

Цитата:

Таблица размещения файлов становится большой. Из-за этого, наверное, и скорость может упасть

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

Цитата:

если PM там чего покоцает... вобщем боюсь его подпускать.

И не надо, подобного рода программы тока структуру тома изменяют, потом траблы лезут... в теме по Windows XP этот вопрос поднимался...

Цитата:

А если 4к стандарт независимо от размера диска, то возможно поэтому NTFS проигрывает FAT'y на дисковых операциях (ессно после дефрагментации дело было ). Точных цифр (и подробностей) не помню, что-то около 10%, кому интересно где-то на ixbt тесты были.

Те тесты, на хоботе, проводились при царе горохе (Опубликовано -- 10 октября 2000 г.), размеры разделов и дисков были иными, системы (как операционные, так и файловые) тоже... воды много с тех пор утекло. Не верьте никому, что NTFS может проигрывать FAT, тем более на больших томах... все, с точностью наоборот, чем больше размер тома, тем вольготней NTFS себя чувствует и тем быстрее она FAT'а...
Читаем:

Цитата:

Disk subsystem performance is a critically important factor in overall system performance, and NTFS is generally believed to be slower than FAT. However, with a correctly created NTFS volume, NTFS performance optimizations, and improved disk defragmentation, NTFS performance (including the extra "journaling") is equivalent to FAT on small disks and is faster than FAT on large disks.

тута http://www.microsoft.com/whdc/hwdev/tech/storage/ntfs-preinstall.mspx

Цитата:

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

Подскажите, почему производительность увеличивается с увеличением размера кластера?

Для меньшего размера кластера надо побольше оперативки.
Я думаю, что именно в этом и есть суть увеличения/уменьшения производительности.

Все-таки хотелось бы услышать более внятные объяснения. Например, что-то типа: Большой файл (фильм) будет копироваться быстрее, если головка будет читать по (к примеру) 64Кб, а не по 512Б. Вот не знаю, возвращается ли головка после каждого кластера в зону хранения данных о местонахождении кластеров, чтобы прочитать информацию о местонахождении следующего, или же такая информация записывается в какой-нибудь кэш. Если записывается в кэш, то мне не понятно, почему есть разница в производительности между 512Б и 4 и больше КБ.

Неужели никто внятно не может объяснить, почему 64кб кластеры считываются быстрее, чем 512б ?

jay007

Цитата:

Неужели никто внятно не может объяснить, почему 64кб кластеры считываются быстрее, чем 512б ?

Ну совсем внятно, микрософт бы обьяснил, но он не горит желанием.
Ихмо. Впринципе для современных хардов и процессоров особо большой разницы нет.
Процессор успеет и одну транзикцию на 64к обработать и 128 транзикций для кластеров в 512б. харду эти потуги фиолетовы, он по своему алгоритму со своим кешем работает. и последовательные кластеры из кеша отдаст хоть по 64к хоть по 512б практически одинаково. Но вот бри большой фрагментации, думаю что и так понятно, что несколько фрагментов по 64к считать быстрее выйдет. чем много много фрагментов по 512б.Так что если почаще дефрагментацию делать разницы особой не будет заметно.

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

tomset

Но вот бри большой фрагментации, думаю что и так понятно, что несколько фрагментов по 64к считать быстрее выйдет. чем много много фрагментов по 512б.Так что если почаще дефрагментацию делать разницы особой не будет заметно.

1. Дефрагментацию встроенным дефрагментатором вин ХР делать бессмысленно, она фрагментирует винт.
2. Как показала практика виндоусу ХР, вообще. без разницы (1-5% производительности заметит только какой-нибудь тест, пользователь нет) насколько винт фрагментирован у меня есть на работе офисные машины, которые не дефрагментированы год- два и ничего, падения производительности нет.

Цитата:

Неужели никто внятно не может объяснить, почему 64кб кластеры считываются быстрее, чем 512б ?

Не знаю, на сколько тема еще актуальна, но я попробую объяснить на примере:
Был я в давеча в японском ресторане, кроме всего прочего ел рис. Палочками. Ложкой получилось бы быстрее. Так и здесь, если файл фрагментирован (рис рассыпчатый) то его нужно вылавливать по всему винту, головки бегают, собирают (каждое зернышко вылавливаю палочками), а если файл нефрагментирован (рис комочками), то не важно какой размер кластера (что палочками, что ложкой получится с одинаковой скоростью).
. Так вот винда очень любит рассыпчатый рис. Даже если места на диске полно, она не пишет файл в соседние кластеры! Но, в принципе, можно заставить винду при наличии искать место для записи в подряд-стоящие кластеры, что-бы при этом размер кластера не играл ни какого рояля.

**Кажется произошел дубляж, я не увидел два вышестоящих сообщения (но может кулинарное сравнение покажется более понятным

Цитата:

Но, в принципе, можно заставить винду при наличии искать место для записи в подряд-стоящие кластеры, что-бы при этом размер кластера не играл ни какого рояля.

Если не секрет, то как это сделать?

Horungy
Uzhe zagorelsya mysl'yu " заставить винду при наличии искать место для записи в подряд-стоящие кластеры " !!!
Programmi v rozyske !

D555

Цитата:

Programmi v rozyske !

Или может штатные средства есть? Не нахожу я ответа на вопрос КАК МОЖНО
"заставить винду при наличии искать место для записи в подряд-стоящие кластеры "????