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

[myhouse_1991]

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

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

Расширенный ответ на вопрос:
Тесты показывают (https://ejrh.wordpress.com/2012/10/26/cluster-size-experiment/), что разница между стандартным размером кластера и повышенным непринципиальная при отсутствии фрагментации. Если заранее позаботиться об организации дефрагментации, то стандартный размер кластера итак выдаст высокую производительность и будет оптимально расходовать место на жестком диске. Резкий скачек фрагментации будет происходить в том случаи, когда жесткий диск будет близок к переполнению. Теоретически есть преимущество у максимального размера кластера в уменьшении MFT и при накоплении фрагментации. Насколько эта эффективность повышается - не проверено.

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

[Игорь Лейко]

Имеет ли смысл выставлять его сразу по максимуму? »
А смысл? Шоб було?

[joystick8000]

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

Верно ли утверждение того, что встроенная дефграментация не работает или эта статья актуальна только для старых версий Windows?
Цитата http://www.oszone.net/1286/:
Типичный размер кластера для NTFS - 4 Кбайта. Стоит отметить, что с большим размером кластера отключается встроенная в файловую систему возможность сжатия индивидуальных файлов, а также перестает работать встроенный API дефрагментации - т.е. подавляющее число дефрагментаторов, в том числе встроенный в Windows 2000, будут неспособны дефрагментировать этот диск »

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

[myhouse_1991]

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

[Vadikan]

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

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

[myhouse_1991]

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

[Iska]

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

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

[joystick8000]

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

[Iska]

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

[myhouse_1991]

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

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

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

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

[joystick8000]

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

[Игорь Лейко]

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

Доступ к большим файлам с большим размером кластера быстрее. »
Нет.

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

[joystick8000]

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

[Игорь Лейко]

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

[joystick8000]

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

[Игорь Лейко]

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

[myhouse_1991]

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

[myhouse_1991]

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

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

граблях вроде отсутствия сжатия NTFS при кластере >4kb. »
Ещё есть грабли. Краш дамп также не работает, если сделать системный раздел с размером кластера более чем 4096 байт.

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

[Vadikan]

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

[Игорь Лейко]

Я сначала ищу в интернете. »
А почему не у Руссиновича?