Установка

Игорь Лейко · Отправлено: **02:03, 17-12-2014** | #2

Цитата myhouse_1991:

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

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

joystick8000 · Отправлено: **02:12, 17-12-2014** | #3

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

Цитата myhouse_1991:

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

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

myhouse_1991 · Отправлено: **05:03, 17-12-2014** | #4

Цитата Игорь Лейко:

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

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

Vadikan · Конфигурация компьютера

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

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

myhouse_1991 · Отправлено: **20:59, 17-12-2014** | #6

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

Iska · Отправлено: **22:07, 17-12-2014** | #7

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

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

joystick8000 · Отправлено: **16:15, 18-12-2014** | #8

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

Iska · Отправлено: **16:34, 18-12-2014** | #9

Цитата joystick8000:

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

Это как раз:

Цитата Iska:

В ряде случаев это неизбежно »

myhouse_1991 · Отправлено: **17:48, 18-12-2014** | #10

Цитата Iska:

Как ОС распределяет пространство при записи? »

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

Цитата Iska:

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

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

Цитата Iska:

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

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

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