Выбор размера кластера при объёмном HDD
 

Хотелось бы больше знать про грамотное использование размера кластера. Имеется объёмный терабайтный жесткий диск и, следовательно, неразумное использование объёма мало волнует при повышении размера кластера в файловой системе NTFS. Имеет ли смысл выставлять его сразу по максимуму? Какие грабли могут быть?

Краткий ответы на вопрос - использовать стандартный размер кластера.

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

Грабли при использовании повышенного размера кластера:
1) Невозможно использовать шифрование или сжатие средствами NTFS.
2) Если сделать системный раздел с повышенным размером кластера, то будет невозможно создавать дамп при BSOD'е.

А смысл? Шоб було?

Если только большие файлы хранить, которые размером больше чем 4к тогда надо ставить больший размер, а если файлы мелкие будут меньше 4 к тогда они все равно будут занимать 4к, как-то так. Доступ к большим файлам с большим размером кластера быстрее. Если кол-во файлов размером меньше чем 64к будет значительно меньше чем файлов больших, то можно и пожертвовать небольшим пространством диска.
Утилита Defrag.exe от windows 7 будет работать с кластером 64к.

В XP это уже было устранено.

Если без субъективности с подтверждением того, что всё это бессмысленно? Как я понял, технически MFT меньше имеет записей, жесткий диск меньше подвержен фрагментации. Учитывая, что на домашнем ПК, в основном, место занимают файлы мультимедия, то они явно не весят мелкими файлами. Это мне начинает напоминать на попытку сэкономить место, убрав восстановление системы. В oszone нет подробных исследований, опровергающий полезность максимального количества кластеров.

myhouse_1991, на томе с ОС будут десятки тысяч мелких файлов, нет никакого смысла. На прочих томах - ставьте какой угодно, разница в производительности будет теоретическая, но помните о граблях вроде отсутствия сжатия NTFS при кластере >4kb.

Резюме: не морочьте себе голову размером кластера.

Сейчас есть объёмные терабайтные жесткие диски. Увеличив размер кластера, MFT будет меньше по размеру, его будет проще обрабатывать при более плотном заполении HDD, будет меньше подвержен фрагментированию. Если проверять в стиле здесь и сейчас, то разницу между стандартным размером кластера и с максимальным не увидим. Интересует больше то, что будет со временем использования. Насколько увеличится противодействие замедлению работы с повышенным размером кластера после проведений различных файловых операции в течении месяца? Насколько увеличится противодействие фрагментации? Станет ли проще обслуживать жесткий диск против фрагментации и потребуется ли для этого меньше времени для дефрагментатора? Неужели при нынешних размерах настолько жалко отдать несколько процентов памяти от жёсткого диска для противодействия замедлению системы в будущем? И вообще насколько в принципе увеличится противодействие замедлению работы со временем использования?

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

Вы понимаете, как и из-за чего возникает фрагментация? Как ОС распределяет пространство при записи? Вот, скажем, есть в uTorrent такой параметр, как «Распределять все файлы», означающий на деле «сразу создавать файлы потребного размера до непосредственной загрузки их содержимого». Понимаете, как этот параметр влияет на фрагментацию?

Iska, Оптимизированные сценарии это как? Например я редактирую документ, сохраняю, потом пишу на диск кучу всего, запись произошла после документа, потом вдруг я решил отредактировать еще раз документ и добавить туда много данных, и тогда мой оптимизированный сценарий редактора начинает вначале подсчитывать bitmap потом перемещать файлы в свободную область, потом дописывать мой документ и потом уплотнять из свободного места к моего документу перенесенные файлы? Это ж какие долгие программы будут, и на сколько увеличится износ, тогда становится вопрос стоит ли пользоваться NTFS? Хотя есть такие случае когда торрент шалит и на системах более устойчивых к фрагментации. Наверное вывод в том что фрагментация неотъемлемая часть работы систем которые поддерживают перезапись.

Это как раз:

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

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

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

В общем, я сделал такие выводы:
1) Если фрагментации нет и есть удобное расположение кластеров для записи файлов, то разница со стандартным размером кластера будет незаметной, но придётся жертвовать объёмом.
2) Можно предположить, что повышенный размер кластера уменьшает вероятность возникновения сценария с неудобным расположением кластеров, а если они возникнут, то за счёт повышенного размера кластера можно будет считать больше данных. Соотвественно фрагментироваться он будет меньше или меньше будет подвержен отрицательному влиянию фрагментации. Вопрос будет в том, насколько эта вероятность снижается и насколько жесткий меньше подвержен отрицательному влиянию фрагментации при различных стечений обстоятельств. Если разница будет невелика, то можно будет с полной увереностью признать стандартный вариант оптимальным вариантом. Остаётся лишь грамотно организовать проверку.

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

А что, есть подтверждение практического смысла этой операции? Метод "я скажу все, что в голову придет, а вы меня опровергайте" нечестен, Вам не кажется?

Нет.

Можно много чего напредполагать. Лучше все-таки держаться в рамках фактов. ;)

Игорь Лейко, Почему нет? Если у меня не SSD, и мне плевать на образование хвостов.
Теперь мне уже стало интересно о большем размере кластера.

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

Игорь Лейко, подробнее можно?

О чем подробнее? О том, чего нет? :)

Почему тогда сразу не поставить 512 байт? Тогда место впустую будет расходоваться ещё меньше, а скорость всё равно не изменится.

Почему тогда сразу не поставить 512 байт? Тогда место впустую будет расходоваться ещё меньше, а скорость всё равно не изменится. Однако выяснится, что он будет хуже.

Я сначала ищу в интернете. Ответы мутные в виде просто используй 4096 байт. Если был бы подробный тест с полным подтверждением бессмысленности при разных условиях фрагментации - данной темы бы и не было.

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

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

А зачем доводить до адской фрагментации, если можно дефрагментировать вовремя? Точнее, ОС это сделает сама в фоне. Другими словами, вы интересуетесь бессмыслицей. И если она вам так важна, проводите эксперименты сами, публикуйте результаты.

А почему не у Руссиновича?

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

Это длинная история, ведущая начало с 80-х годов прошлого века. Преимущественно для возможности использования больших дисков.
Можно вспомнить, например, кластеры 128 Кб в NTFS 1.4.
И сейчас в NTFS 3.1, а точнее в актуальных версиях ntfs.sys, могут потребоваться кластеры больше 4 Кб.

В моём случаи, на ПК под управлением Win7, который используется людьми, не шарющих в компах, фрагментация доходила выше 50% на терабайтнике. Может быть там что-то было сделано неправильно, но там не стоял отдельный дефрагментатор и в планировщике включён встроенный.

1) Может быть вы знаете. Не подскажите программы которые бы выводили карту кластеров и где файл расположен по кластерам? Можно скачать продвинутый дефрагментатор, который итак умеет это делать, но может быть есть просто отдельные программы для такой цели? DiskView из Sysinternals работает под старые Windows NT 5.X системы.
2) Как правильно отключить кеширование? Чтобы не получилось так, что файл считался из ОЗУ или какого-нибудь другого кеша.

Как определили? Разные дефрагментаторы считают по-разному.

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

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

Переделана шапка темы для поисковиков.