Какой размер кластера для ssd windows 10

Размер кластера по умолчанию для файловых систем FAT, NTFS и exFAT

Аннотация

Во всех файловых системах, используемых Windows, дисковое пространство организовывается с учетом размера кластеров (или размера единицы распределения). Размер кластера — минимальный объем дискового пространства, который может быть выделен для хранения файла. Таким образом, если размер файла не кратен размеру кластера, для его хранения необходимо использовать дополнительное пространство (кратное размеру кластера). При обычном разделении пространства на жестком диске средний объем памяти, потерянной в таком случае, можно рассчитать по формуле (размер кластера)/2 * (количество файлов).

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

Дополнительная информация

Раздел (том) жесткого диска можно отформатировать под файловую систему NTFS, FAT или exFAT. В зависимости от метода форматирования раздела в Windows могут использоваться следующие значения по умолчанию.

С помощью команды FORMAT без указания размера кластера.

С помощью программы Windows Explorer, когда в поле Единица размещения в диалоговом окне Формат оставлено значение Стандартный размер размещения.

По умолчанию размер кластера для файловой системы NTFS в Windows NT 4.0 и более поздних версий равен 4 КБ. Это обусловлено тем, что сжатие файлов в NTFS невозможно для дисков с большим размером кластера. Команда форматирования не использует размер кластера больше 4 КБ, кроме случая, когда пользователь переопределяет значения по умолчанию. Вы можете сделать это, используя /А: переключение вместе с командой Format или с помощью указания большего размера кластера в соответствующем поле при форматировании с помощью проводника.

Размеры кластера по умолчанию для файловой системы NTFS

В следующей таблице описаны размеры кластера по умолчанию для NTFS.

Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP и Windows 2000

Источник

🛠 Настраиваем и оптимизируем работу SSD-накопителя в Windows и Ubuntu

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

Команда TRIM

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

Чтобы определить состояние TRIM в Windows введем в консоли:

DisableDeleteNotify = 1 – TRIM отключен

DisableDeleteNotify = 0 – TRIM включен

Рис. 1. Определение состояния службы TRIM в Windows

Для включения TRIM введем в командной строке:

Для выключения TRIM:

Проверим, включена ли команда TRIM в Ubuntu следующей командой:

Если у столбцов DISC-GRAN и DISC-MAX нулевые значения, то TRIM выключен.

Рис. 2. Определение состояния службы TRIM в Ubuntu

Чтобы запустить TRIM вручную, введем в терминале команду:

Служба SysMain

Служба SysMain (Windows 10) в предыдущих версиях Windows называлась Superfetch. Когда ОЗУ недостаточно, SysMain не записывает данные в файл подкачки, а сжимает их в ОЗУ. Также служба объединяет страницы с одинаковым содержимым. Получаем снижение объема записи на диск. Отключать нет смысла.

Как проверить состояние SysMain:

Служба Prefetcher

Как проверить состояние Prefetch:

Система индексирования Windows

Как отключить индексацию файлов:

Режим гибернации

Режим гибернации сохраняет содержимое оперативной памяти на SSD перед выключением компьютера. При включении данные с SSD загружаются в ОЗУ. Если сверхбыстрый запуск ОС не нужен, а достаточно быстрого запуска с SSD, то гибернацию можно отключить.

Чтобы отключить гибернацию в Windows откроем консоль и введем:

Для включения гибернации используем команду:

Точки восстановления системы

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

Как проверить состояние точек восстановления:

Быстрый доступ к настройкам восстановления системы:

Служба дефрагментации и автоматического обслуживания

Начиная с Windows 7 система научилась определять тип накопителя и отключает дефрагментацию для SSD, а взамен выполняет TRIM. Как оказалось, не всегда.

Как посмотреть состояние службы дефрагментации:

Чтобы посмотреть журнал оптимизации и дефрагментации дисков откроем PowerShell из меню пуск и введем следующую команду:

Мои диски С и P расположены на твердотельных накопителях и Windows почему-то провела дефрагментацию этих дисков. Это связано с тем, что я переустанавливал Windows и это было первое выполнение задачи оптимизации по расписанию. Потом ОС выполняла только оптимизацию дисков.

Рис. 9. Журнал дефрагментации и оптимизации SSD-накопителя в Windows

Файл подкачки

Когда ОЗУ недостаточно, Windows обеспечивает надежную работы программы, перемещая неиспользуемые данные на диск в файл подкачки. При его отключении некоторые программы могут работать некорректно, поэтому рекомендуется выбирать его размер в автоматическом режиме. Если файл подкачки неоправданно велик, то задать его размер вручную.

Настройка файла подкачки:

Выравнивание разделов

Разделы выравнивают, чтобы физические ячейки объема соответствовали логическим ячейкам и сократилось количество дисковых операций. Если разделы отличаются по длине – один кластер перекрывает два блока секторов, как в HDD, – удваивается число операций чтения и записи, накопитель работает медленнее и повышается его износ (рис. 11 ).

Рис. 11. Иллюстрация не выровненных разделов в HDD

В SSD также нужно выравнивать разделы, чтобы продлить срок службы накопителя.

Чтобы узнать размер кластера в Windows введем в консоли:

Рис. 13. Информация о размере сектора и кластера в Windows

Как изменить размер кластера в Windows:

Как узнать размер кластера в Ubuntu:

/dev/sda1 – путь к разделу.

Рис. 14. Информация о размере сектора и кластера в Ubuntu

Как изменить размер кластера в Ubuntu (все данные будут удалены):

mkfs.ntfs – форматирование в NTFS ( mkfs.ext4 – форматирование в ext4).

-c – проверка на наличие битых блоков на устройстве.

4096 – размер кластера.

Как узнать выровнен ли раздел в Windows:

Как узнать выровнен ли раздел в Ubuntu:

1 – номер раздела. Например, у sda1 будет единица.

Рис. 16. Проверка, выровнен раздел в Ubuntu или нет

Чтобы узнать номер раздела введем в консоли:

На что смотреть при покупке SSD

У твердотельных дисков есть два параметра, которые определяют его долговечность:

Чем больше значение этих параметров, тем лучше.

Рис. 17. Количество циклов перезаписи SSD-накопителя с разными типами памяти

Как оптимизировать работу SSD-накопителя

Мы узнали какие службы действительно продлевают жизнь и ускоряют твердотельный накопитель, а какие нет. Про SSD для рядового потребителя можно сказать одно – установил и забыл, так как все важные службы работают в автоматическом режиме, а ненужные отключены.

Источник

Какие факторы влияют на производительность систем хранения и как?

Системы хранения данных для подавляющего большинства веб-проектов (и не только) играют ключевую роль. Ведь зачастую задача сводится не только к хранению определенного типа контента, но и к обеспечению его отдачи посетителям, а также обработки, что накладывает определенные требования к производительности.

В то время, как при производстве накопителей используется множество других метрик, чтоб описать и гарантировать должную производительность, на рынке систем хранения и дисковых накопителей, принято использовать IOPS, как сравнительную метрику, с целью «удобства» сравнения. Однако производительность систем хранения, измеряемая в IOPS (Input Output Operations per Second), операциях ввода / вывода (записи / чтения), подвержена влиянию большого множества факторов.

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

Начнем с того, что IOPS вовсе не IOPS и даже совсем не IOPS, так как существует множество переменных, которые определяют сколько IOPS мы получим в одних и других случаях. Также следует принять во внимание, что системы хранения используют функции чтения и записи и обеспечивают различное количество IOPS для этих функций в зависимости от архитектуры и типа приложения, в особенности в случаях, когда операции ввода / вывода происходят в одно и тоже время. Различные рабочие нагрузки предъявляют различные требования к операциям ввода / вывода (I/O). Таким образом, системы хранения, которые на первый взгляд должны были бы обеспечивать должную производительность, в действительности могут не справится с поставленной задачей.

Основы производительности накопителей

Для того, чтоб приобрести полноценное понимание в вопросе, начнем с основ. IOPS, пропускная способность (MB/s или MiB/s) и время отклика в миллисекундах (мс) являются общепринятыми единицами измерения производительности накопителей и массивов из них.

IOPS обычно рассматривают в ключе измерения способности устройства хранения производить чтение / запись блоками размером 4-8КБ в случайном порядке. Что типично для задач онлайн-обработки транзакций, баз данных и для запуска различных приложений.

Понятие пропускной способности накопителя обычно же применимо при чтении / записи крупного файла, к примеру, блоками 64КБ и более, последовательно (в 1 поток, 1 файл).

Время отклика — время, которое необходимо накопителю для того, чтоб начать производить операцию записи / чтения.

Преобразование между IOPS и пропускной способностью может быть выполнено следующим образом:

IOPS = пропускная способность / размер блока;
Пропускная способность = IOPS * размер блока,

где размер блока — количество информации, переданное на протяжении одной операции ввода / вывода (I/O). Таким образом, зная такую характеристику жесткого диска (HDD SATA), как пропускную способность — мы с легкостью можем вычислить количество IOPS.

К примеру, возьмем стандартный размер блока — 4КБ и стандартную пропускную способность, заявленную производителем для последовательной записи или чтения (I/O) — 121 Мбайт / с. IOPS = 121 МБ / 4 КБ, в результате чего получим значение порядка 30 000 IOPS для нашего жесткого диска SATA. Если же размер блока увеличить и сделать равным 8 КБ, значение будет порядка 15 000 IOPS, то есть снизится практически пропорционально увеличению размера блока. Однако нужно четко понимать, что тут мы рассматривали IOPS в ключе последовательной записи или чтения.

Все меняется драматическим образом для традиционных жестких SATA дисков, если чтение и запись будут случайными. Тут начинает играть роль задержка (latency), которая очень критична в случае жестких дисков HDDs (Hard Disk Drives) SATA / SAS, а порой даже и в случае твердотельных накопителей SSD (Solid State Drive). Хотя последние зачастую обеспечивают производительность на порядки лучшую, чем у «вращающихся» накопителей, за счет отсутствия движущихся элементов, но все же могут возникать ощутимые задержки при записи, в виду особенностей технологии, и, как следствие, при использовании их в массивах. Глубокоуважаемый amarao провел довольно полезное исследование по использованию твердотельных накопителей в массивах, как выяснилось, производительность будет зависеть от latency самого медленного из дисков. Более подробно с результатами Вы можете ознакомиться в его статье: SSD + raid0 — не всё так просто.

Но вернемся к производительности отдельно взятых накопителей. Рассмотрим случай с «вращающимися» накопителями. Время, требуемое для выполнения одной случайной операции ввода / вывода будет определятся такими составляющими:

где T(A) — время доступа (access time или seek time), также известное, как время поиска, то есть время, требуемое для того, чтоб считывающая головка, была помещена на дорожку с нужным нам блоком информации. Зачастую в спецификации диска производителем указываются 3 параметра:

— время, требуемое, чтоб переместиться с самой дальней дорожке к самой ближней;
— время, требуемое для перемещения между смежными дорожками;
— среднее время доступа.

Таким образом мы приходим к волшебному выводу, что показатель T(A) может быть улучшен, если мы размещаем наши данные на как можно более близких дорожках, а все данные располагаются как можно дальше от центра пластины (требуется меньше времени для перемещения блока магнитных головок, а на внешних дорожках данных больше, так как больше длина дорожки и она вращается быстрее, нежели внутренняя). Теперь становится понятно почему дефрагментация может быть так полезна. Особенно с условием размещения данных на внешних дорожках в первую очередь.

T(L) — задержка, вызванная вращением диска, то есть время, требуемое для того, чтоб считать или записать конкретный сектор на нашей дорожке. Легко понять, что оно будет лежать в пределах от 0 до 1/RPS, где RPS — количество оборотов в секунду. К примеру при характеристике диска в 7200 RPM (оборотов в минуту) мы получим 7200/60 = 120 оборотов в секунду. То есть один оборот происходит за (1/120) * 1000 (количество миллисекунд в секунде) = 8,33 мс. Средняя же задержка в этом случае, будет равна половине времени, затрачиваемому на один оборот — 8,33/2 = 4,16 мс.

T(R/W) — время чтения или записи сектора, которое определяется размером выбранного при форматировании блока (от 512 байт и до… нескольких мегабайт, в случае с более емкими накопителями — от 4 килобайт, стандартный размер кластера) и пропускной способностью, которая указана в характеристиках накопителя.

Среднюю задержку вращения, которая приблизительно равна времени, затраченному на половину оборота, зная скорость вращения 7200, 10 000 или 15 000 RPM, легко определить. И выше мы уже показали как.

Остальные же параметры (среднее время поиска чтения и записи) определить сложнее, они определяются уже в результате тестов и указываются производителем.

Для расчета количества случайных IOPs жесткого диска возможно применить следующую формулу, при условии когда количество одновременных операций чтения и записи одинаково (50%/50%):

1/( ( (среднее время поиска чтения + среднее время поиска записи) / 2) / 1000) + (средняя задержка вращения / 1000)).

Многие интересуются, почему именно такое происхождение формулы? IOPS — количество операций ввода или вывода в секунду. Именно потому мы делим в числителе 1 секунду (1000 миллисекунд) на время с учетом всех задержек в знаменателе (выраженное также в секундах или миллисекундах), требуемое для осуществления одной операции ввода или вывода.

То есть формула может быть записана и таким образом:

1000 (мс) / ((среднее время поиска чтения (мс) + среднее время поиска записи (мс)) /2) + средняя задержка вращения (мс))

Для накопителей с различным количеством RPM (вращений в минуту), мы получим следующие значения:

Для 7200 RPM накопителя IOPS = 1/(((8,5+9,5)/2)/1000) + (4,16/1000)) = 1/((9/1000) +
(4,16/1000)) = 1000/13,16 = 75,98;
Для 10K RPM SAS накопителя IOPS = 1/(((3,8+4,4)/2)/1000) + (2,98/1000)) =
1/((4,10/1000) + (2,98/1000)) = 1000/7,08 = 141,24;
Для 15K RPM SAS накопителя IOPS = 1/(((3,48+3,9)/2)/1000) + (2,00/1000)) =
1/((3,65/1000) + (2/1000)) = 1000/5,65 = 176,99.

Таким образом мы видим драматические изменения, когда с десятков тысяч IOPS при последовательном чтении или записи, производительность падает до нескольких десятков IOPS.

И уже, при стандартном размере сектора в 4КБ, и наличию столь малого числа IOPS, мы получим значение пропускной способности отнюдь не в сотню мегабайт, а менее, чем в мегабайт.

Эти примеры также иллюстрируют причину незначительных изменений в номинальных дисковых IOPS от разных производителей для дисков с одним и тем же показателем RPM.

Теперь становится понятным, почему данные производительности, лежат в довольно широких диапазонах:

7200 RPM (Rotate per Minute) HDD SATA — 50-75 IOPS;
10K RPM HDD SAS — 110-140 IOPS;
15K RPM HDD SAS — 150-200 IOPS;
SSD (Solid State Drive) — десятки тысяч IOPS на чтение, сотни и тысячи на запись.

Однако номинальный дисковый IOPS остается все же далеко неточными, так как не учитывает различий в характере нагрузок в отдельно взятых случаях, что очень важно понимать.

Также, для лучшего понимания темы, рекомендую ознакомиться еще с одной полезной статьей от amarao: Как правильно мерять производительность диска, благодаря которой становиться также понятным, что latency вполне не фиксирована и также зависит от нагрузки и ее характера.

Единственное, хотелось бы добавить:

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

Мы уже поняли, что для «вращающихся» накопителей, время, требуемое для случайного чтения или записи, складывается из следующих компонент:

И далее даже рассчитали производительность при случайном чтении и записи в IOPS. Вот только параметром T(R/W) мы там по сути пренебрегли, и это не случайно. Мы знаем, что допустим, последовательное чтение может быть обеспечено на скорости в 120 мегабайт в секунду. Становится понятным, что блок в 4КБ, будет считан за примерно 0,03 мс, время на два порядка меньшее, нежели время остальных задержек (8 мс + 4 мс).

Таким образом, если при размере блока в 4КБ мы имеем 76 IOPS (основная задержка была вызвана вращением накопителя и временем позиционирования головки, а не самим процессом чтения или записи), то при размере блока в 64КБ, падение IOPS будет не в 16 раз, как при последовательном чтении, а лишь на несколько IOPS. Так как время, затрачиваемое на непосредственно чтение или запись, возрастет на 0,45 мс, что составляет лишь порядка 4% от общего времени задержки.

В результате мы получим 76-4% = 72,96 IOPS, что согласитесь, совсем не критично при расчетах, так как падение IOPS не в 16 раз, а лишь на несколько процентов! И при расчетах производительности систем куда важнее не забыть учесть другие важные параметры.

Волшебный вывод: при расчете производительности систем хранения, основанных на жестких дисках, следует подбирать оптимальный размер блока (кластера), для обеспечения нужной нам максимальной пропускной способности в зависимости от типа данных и используемых приложений, причем падением IOPS при увеличении размера блока с 4КБ до 64КБ или даже 128КБ можно пренебречь, либо учитывать, как 4 и 7% соответсвенно, если в поставленной задаче они будут играть важную роль.

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

Оптимальный размер блока (кластера)

Оптимальный размер блока нужно учитывать в зависимости от характера нагрузки и типа используемых приложений. Если идет работа с данными небольшого размера, к примеру с базами данных — следует выбрать стандартные 4 КБ, если же речь идет о стриминге видеофайлов — размер кластера лучше выбирать от 64 КБ и более.

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

Почему стандарт 4 КБ?

Для многих накопителей, в особенности твердотельных, значения производительности, к примеру записи, начиная с 4 КБ, становятся оптимальными, это видно из графика:

В то время, как на чтение, скорость также довольно существенна и более менее сносна начиная с 4 КБ:

Именно по этой причине 4 КБ размер блока очень часто применяют за стандартный, так как при меньшем размере идут большие потери производительности, а при увеличении размера блока, в случае работы с небольшими данными, данные будут распределены менее эффективно, занимать весь размер блока и квота накопителя будет использоваться не эффективно.

Уровень RAID

Если Ваша система хранения представляет собой массив накопителей объединенных в RAID определенного уровня, то производительность системы будет зависеть в значительной степени от того, какой именно уровень RAID был применен и какой процент от общего числа операций приходится на операции записи, ведь именно запись является причиной снижения производительности в большинстве случаев.

Так, при RAID0, на каждую операцию ввода будет расходоваться лишь 1 IOPS, ведь данные будут распределены по всем накопителям без дублирования. В случае же зеркала (RAID1, RAID10), каждая операция записи будет потреблять уже 2 IOPS, так как информация должна быть записана на 2 накопителя.

В более высоких уровнях RAID потери еще существеннее, к примеру в RAID5 штрафной коэффициент будет уже 4, что связано с тем, каким образом данные распределяются по дисках.

RAID5 используется вместо RAID4 в большинстве случаев, так как распределяет четность (контрольные суммы) по всем дискам. В массиве RAID4 один из дисков ответственен за всю четность, в то время как данные распространены более чем на 3 диска. Именно потому мы применяем штрафной коэффициент 4 в массиве RAID5, так как мы читаем данные, читаем четность, затем пишем данные и пишем четность.

В массиве RAID6 все аналогично, за исключением того, что мы вместо вычисления четности единожды, делаем это дважды и таким образом имеем 3 операции чтения и 3 записи, что дает нам уже штрафной коэффициент 6.

Казалось бы, что в таком массиве, как RAID-DP все будет аналогично, так как это по сути модифицированный массив RAID6. Но не тут то было… Хитрость заключается в том, что применяется отдельная файловая система WAFL (Write Anywhere File Layout), где все операции записи последовательны и производятся на свободное место. WAFL в основном напишет новые данные в новое местоположение на диске и затем переместит указатели на новые данные, устраняя таким образом операции чтения, которые должны иметь место. Кроме того идет запись журнала в NVRAM, который отслеживает транзакции записи, инициирует запись и может восстановить их при необходимости. Идет запись в буфер в начале, а затем они уже «сливаются» на диск, что ускоряет процесс. Вероятно эксперты в NetApp могут просветить нас более подробно в комментариях, за счет чего достигается экономия, я пока что еще не до конца разобрался в этом вопросе, но запомнил, что штрафной коэффициент RAID будет всего лишь 2, а не 6. «Хитрость» весьма существенна.

При больших массивах RAID-DP, которые состоят из десятков дисков, существует понятие уменьшения «штрафа четности», который возникает при записи четности. Так при росте массива RAID-DP, требуется меньшее количество дисков, выделяемых под четность, что приведет к снижению потерь, связанных с записями четностей. Однако в небольших массивах, либо с целью повышения консерватизма, мы можем пренебречь этим явлением.

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

В случае пренебрежения этими факторами, формула будет следующей:

Функциональные IOPS = (Исходные IOPS * % операций записи / штрафной коэффициент RAID) + (Исходные IOPS * % чтения), где Исходные IOPS = усредненный IOPS накопителей * количество накопителей.

Рассчитаем для примера производительность массива RAID10 из 12 дисков HDD SATA, если известно, что одновременно происходит 10% операций записи и 90% операций чтения. Допустим, что диск обеспечивает 75 случайных IOPS, при размере блока 4КБ.

Исходные IOPS = 75*12 = 900;
Функциональные IOPS = (900*0,1/2) + (900*0,9) = 855.

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

В целях консерватизма я рекомендую добавлять от 20% от нужного числа IOPS, при проектировании систем.

Зависимость от приложений

Производительность нашего решения очень сильно может зависеть от приложений, которые будут исполнятся впоследствии. Так это может быть обработка транзакций — «структурированных» данных, которые организованы, последовательны и предсказуемы. Зачастую в этих процессах можно применить принцип пакетной обработки, распределив эти процессы во времени так, когда нагрузка минимальна, тем самым оптимизировав потребление IOPS. Однако в последнее время появляется все больше и больше медийных проектов, где данные «не структурированы» и требуют совсем иных принципов их обработки.

По этой причине подсчет необходимой производительности решения для конкретного проекта может стать весьма сложной задачей. Некоторые из производителей сторедж-хранилищ и экспертов утверждают, что IOPS не имеют значения, так как клиенты в подавляющем большинстве используют до 30-40 тысяч IOPS, в то время, как современные системы хранения обеспечивают сотни тысяч и даже миллионы IOPS. То есть современные хранилища удовлетворяют нужды 99% клиентов. Тем не менее это утверждение может быть справедливо далеко не всегда, лишь для бизнес-сегмента, который размещает хранилища у себя, локально, но не для проектов, размещаемых в дата-центрах, которые зачастую, даже при использовании готовых решений хранения, должны обеспечивать довольно высокую производительность и отказоустойчивость.

В случае размещения проекта в дата-центре, в большинстве случаев, все же более экономично строить системы хранения самостоятельно на основе выделенных серверов, нежели использовать готовые решения, так как становится возможным более эффективно распределить нагрузку и подобрать оптимальное оборудование для тех, либо других процессов. Помимо прочего, показатели производительности готовых систем хранения, далеки от реальных, так как в большинстве своем основаны на данных профилей синтетических тестов производительности, при применении 4 или 8 КБ размера блока, в то время как большинство клиентских приложений работает сейчас в средах с размером блока от 32 до 64 КБ.

Как видим из графика:

Менее, чем 5% систем хранения, настроены с применением блока менее 10 КБ и менее, чем 15% используют блоки с размером менее 20 КБ. Кроме того, даже для определенного приложения, редко когда возникает потребления I/O лишь одного типа. К примеру у базы данных будут различные профили I/O для различных процессов (файлы с данными, логирование, индексы …). А значит, заявленные синтетические тесты производительности систем, могут быть далекими от истины.

А что на счет задержек?

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

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

Хорошо, если ни IOPS, ни время ожидания не являются хорошей мерой измерения производительности системы хранения, то что тогда?

Только реальный тест исполнения приложения на конкретном решении…

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

Тем не менее учет приведенных выше факторов, влияющих на производительность наших систем, может быть весьма полезным при подборе хранилища или построении определенной инфраструктуры на основе выделенных серверов. С определенной степенью консерватизма становится возможным подобрать более-менее реальное решение, исключить некоторые технические и программные изъяны в виде не оптимального размера блока при разбивке или не оптимальной работы с дисками. Решение, конечно, не будет на 100% гарантировать расчетную производительность, но в 99% случаев можно будет говорить, что решение справится с нагрузкой, особенно, если добавлять консерватизм в зависимости от типа приложения и его особенностей в расчет.

Источник

Аннотация

Во всех файловых системах, используемых Windows, дисковое пространство организовывается с учетом размера кластеров (или размера единицы распределения). Размер кластера — минимальный объем дискового пространства, который может быть выделен для хранения файла. Таким образом, если размер файла не кратен размеру кластера, для его хранения необходимо использовать дополнительное пространство (кратное размеру кластера). При обычном разделении пространства на жестком диске средний объем памяти, потерянной в таком случае, можно рассчитать по формуле (размер кластера)/2 * (количество файлов).

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

Дополнительная информация

Раздел (том) жесткого диска можно отформатировать под файловую систему NTFS, FAT или exFAT. В зависимости от метода форматирования раздела в Windows могут использоваться следующие значения по умолчанию.

• С помощью команды FORMAT без указания размера кластера.

• С помощью программы Windows Explorer, когда в поле Единица размещения в диалоговом окне Формат оставлено значение Стандартный размер размещения.

По умолчанию размер кластера для файловой системы NTFS в Windows NT 4.0 и более поздних версий равен 4 КБ. Это обусловлено тем, что сжатие файлов в NTFS невозможно для дисков с большим размером кластера. Команда форматирования не использует размер кластера больше 4 КБ, кроме случая, когда пользователь переопределяет значения по умолчанию. Вы можете сделать это, используя /А: переключение вместе с командой Format или с помощью указания большего размера кластера в соответствующем поле при форматировании с помощью проводника. 

При использовании программы Convert.exe для преобразования раздела FAT в NTFS всегда используется исходный размер кластера FAT в качестве размера кластера NTFS, если он не превышает 4 КБ. Если размер кластера FAT больше 4 КБ, то кластеры преобразовываются к размеру 4 КБ в NTFS/ Это объясняется тем, что структуры файловой системы FAT ориентированы на пределы кластера, и следовательно, установка любого большего размера кластера не позволяет выполнить преобразование. При форматировании раздела с помощью программы установки Windows NT 3.5, 3.51 и 4.0 , он сначала форматируется в FAT, а затем преобразуется в NTFS, а значит, в этом случае размер кластера всегда будет таким, каким был указан ранее при форматировании раздела в Настройках.

Размеры кластера по умолчанию для файловой системы NTFS

В следующей таблице описаны размеры кластера по умолчанию для NTFS.

Размер тома	Windows NT 3.51	Windows NT 4.0	Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP и Windows 2000
7 МБ — 512 МБ	512 байт	4 КБ	4 КБ
512 МБ — 1 ГБ	1 МБ	4 КБ	4 КБ
1 ГБ —2 ГБ	2 ГБ	4 КБ	4 КБ
2 ГБ —2 ТБ	4 КБ	4 КБ	4 КБ
2 ТБ —16 ТБ	Не поддерживается*	Не поддерживается*	4 КБ
16 ТБ —32 ТБ	Не поддерживается*	Не поддерживается*	8 ГБ
32 ТБ —64 ТБ	Не поддерживается*	Не поддерживается*	16 ГБ
64 ТБ —128 ТБ	Не поддерживается*	Не поддерживается*	32 ГБ
128 ТБ —256 ТБ	Не поддерживается*	Не поддерживается*	64 ГБ
> 256 TB	Не поддерживается	Не поддерживается	Не поддерживается

Примечание . Звездочка (*) означает, что он не поддерживается из-за ограничений записи главной загрузки (MBR).

Размер кластера по умолчанию для FAT16

В приведенной ниже таблице указаны значения размеров кластеров по умолчанию для файловой системы FAT16.

Размер тома	Windows NT 3.51	Windows NT 4.0	Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP и Windows 2000
7 МБ —8 МБ	Не поддерживается	Не поддерживается	Не поддерживается
8 МБ —32 МБ	512 байт	512 байт	512 байт
32 МБ —8 МБ	1 МБ	1 МБ	1 МБ
64 ТБ —128 ТБ	2 ГБ	2 ГБ	2 ГБ
128 ТБ —256 ТБ	4 КБ	4 КБ	4 КБ
256 МБ —512 МБ	8 ГБ	8 ГБ	8 ГБ
512 МБ — 1 ГБ	16 ГБ	16 ГБ	16 ГБ
1 ГБ —2 ГБ	32 ГБ	32 ГБ	32 ГБ
2 ГБ —4 ГБ	64 ГБ	64 ГБ	64 ГБ
4 ГБ —8 ГБ	Не поддерживается	128 КБ*	Не поддерживаются
8 ГБ —16 ГБ	Не поддерживается	256 KB*	Не поддерживаются
> 16 ГБ	Не поддерживаются	Не поддерживается	Не поддерживается

Примечание. Символ «*» означает доступность только для носителей с размером сектора, превышающим 512 байт.

Размер кластера по умолчанию для FAT32

В приведенной ниже таблице указаны значения размеров кластеров по умолчанию для файловой системы FAT32.

Размер тома	Windows NT 3.51	Windows NT 4.0	Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP и Windows 2000
7 МБ — 16 МБ	Не поддерживается	Не поддерживается	Не поддерживается
16 МБ —32 МБ	512 байт	512 байт	Не поддерживается
32 МБ —8 МБ	512 байт	512 байт	512 байт
64 МБ —128 МБ	1 МБ	1 МБ	1 МБ
128 ТБ —256 ТБ	2 ГБ	2 ГБ	2 ГБ
256 МБ — 8 ГБ	4 КБ	4 КБ	4 КБ
8—16 ГБ	8 ГБ	8 ГБ	8 ГБ
16 ТБ —32 ТБ	16 ГБ	16 ГБ	16 ГБ
32 ГБ — 2 ТБ	32 ГБ	Не поддерживается	Не поддерживается
> 2 ТБ	Не поддерживаются	Не поддерживается	Не поддерживается

Размер кластера по умолчанию для exFAT

В приведенной ниже таблице указаны значения размеров кластеров по умолчанию для файловой системы exFAT.

Размер тома	Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003 и Windows XP
7 МБ — 256 МБ	4 КБ
256 МБ — 1 ГБ	32 ГБ
32 ГБ — 256 ТБ	128 МБ.
> 256 TБ	Не поддерживаются

Changing the cluster size of a disk is commonly known as switching the disk allocation unit size, which is a breeze. Our digital tools are ideal for business owners and home users who want to adjust the size of their clusters. So, what is cluster size? What are the numerous disc formats, and how does our software make cluster size modification stress-free and easy?

What is Cluster Size?

You must select a cluster size when formatting a solid-state drive (SSD), hard disc drive (HDD), SD card, thumb drive, or any other storage device. The «Allocation Unit Size» feature allows you to change the size of a storage device’s cluster. How your file systems structure your storage device is determined by the cluster size. The least amount of storage space that a single file can utilize during its generation and storage is determined by the cluster size.

The cluster size you select determines how much RAM is available to store and hold one file. The file is subsequently split up and saved on the storage device in many portions. Files that do not fit inside an even multiple of your chosen cluster size take up extra storage space, which is calculated by rounding up to the next even multiple.

A Cluster Size Examples on SSD

If you save a 512-byte file on a partition with a 512-byte cluster size, the file will take up 512 bytes of storage space. Good so far?

When a 525-byte file is stored on a storage device with a 512-byte cluster size, the file takes up 1024 bytes of storage space. Because the partition is assigning the next multiple (1024) of its 512-byte cluster size to hold your file, it takes up more than 525 bytes of storage space.

However, for now, the cluster size of a disk is more than 512, it has more units as shown here:

How to Change SSD Cluster Size?

For Windows, various file system formats determine how your data are organized. NTFS, FAT32, and exFAT are the three file systems available in Windows. And each file system file requires different cluster sizes. So the best way to change an SSD disk cluster size is to change its file system. 

Cluster Size of Different Partition Formats

Let’s check the cluster size of different partition formats first:

Note that Windows only supports FAT32 and NTFS file system formats. Therefore, if it’s an internal SSD disk, you can only select NTFS or FAT32 as its format to switch its cluster. So how to change the cluster size of your SSD? Check the next part, you’ll get two solutions that help to switch disk cluster size.

Recommended Cluster Size of SSD: Note that the larger unite size can lead to more writes over time, causing more wear and tear on SSD, which is not good for its lifespan. SO the recommended cluster size for SSD should be the default: 4K. 

Method 1. Let EaseUS Partition Master Help

At EaseUS, we create technologies that make changing the partition size, cluster size, and recovery procedure on your storage device simple, upfront, and stress-free by using our partition manager software — EaseUS Partition Master. We give lightning-fast support and coaching. We even offer a free version for help. 

You may now download this software and follow the following guidelines to optimize the SSD cluster size to 4K on your own. 

Step 1. Right-click the partition that you need to change its cluster size, select «Advanced» and click «Change Cluster Size».

Step 2. Click the size list below the New size section, and select a desired cluster size you want to adjust for the disk partition, click «OK».

Step 3. Click «Execute 1 Task(s)» and click «Apply» to confirm the operation.

Method 2. Run Disk Management to Change Cluster Size

The other method that you can try is to run Windows Disk Management and run the format operation so as to switch the cluster size for your SSD. Also, don’t format to backup data in advance.

Here are the steps:

Step 1. Right-click Windows icon and click «Search», type create and format hard disk partition, and click to open Disk Management.

Step 2. On Disk Management, right-click on the partition in SSD disk and select «Format Volume».

Step 3. Set a new format for the SSD volume (be it FAT32 or NTFS), and then set the cluster size as 4K, click «OK».

Wait for the process to complete.

Notes: When you complete the formatting, changing the cluster size of SSD, you can now restore the backup of files back to the SSD disk.

Changing SSD Cluster Size, Which Is Better? 4K Alignment or Formatting?

Note that on this page, we provided two ways that help you to adjust the SSD cluster size by using EaseUS Partition Master or applying disk management formatting.

 But which one is better? For a no-data-loss solution, we suggest you pick EaseUS Partition Master for help. Its 4K alignment feature makes the process of adjusting SSD cluster size easy and funny. You just need to click the command button, the rest jobs will all be done by this tool. 

Размер кластера и дисковое пространство — Заметки Сис.Админа

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

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

Сам по себе этот размер задаётся при уже упомянутом форматировании или создании самого раздела. Доступные размеры зависят от файловой системы (NTFS, FAT, exFAT, если мы рассматриваем Windows) и влияют не только на количественные, но и на скоростные характеристики дисковой подсистемы.

Впрочем, давайте обо всём по порядку.

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

Размер же кластера представляет собой наименьший объем дискового пространства, который можно использовать для хранения файла.

Если размеры файлов не достигают четного кратного размера кластера, для хранения файла необходимо использовать дополнительное пространство (до следующего кратного размера кластера). В типичном разделе жесткого диска средний объем пространства, который теряется таким образом, может быть рассчитан с использованием уравнения:

(размер кластера) / 2 * (количество файлов)

Размер кластера в виде наглядного примера

Возможно последнее предложение и формула несколько Вас смутили. Давайте попробуем объяснить проще и нагляднее. Наверняка, открыв свойства какой-то папки, Вы сталкивались с такой картиной:

Т.е размер папки с файлами и фактический размер занятого пространства на диске, собственно, отличаются в большую или меньшую сторону. Это как раз связано с размером кластера, выбранным Вами (или системой) при форматировании/создании раздела.

Еще раз, — кластер, — это наименьший логический объем дискового пространства, который может быть выделен для хранения файла. Теперь попробуйте представить, что Ваш диск состоит из множества множества ячеек со своей нумерацией, куда можно положить файл. Наиболее наглядно это видно при дефрагментации (хотя там наиболее часто показан блок файловой системы, а не кластер, но всё же):

Размер этих ячеек и есть размер кластера. Теперь о том, как с этим взлетать.

Как с этим взлетать и что стоит понимать

Визуально Вы думаю представили, как оно выглядит. Давайте разбираться как работает.

Предположим, что размер кластера равен 4 КБ (как правило, — это значение по умолчанию, не считая самых старших версий систем). Так устроено, что файл, меньшего размера, помещенный туда всё равно будет занимать 4 КБ. Наглядный пример:

Два файла меньшего размера уже 8 Кб:

Т.е, условно говоря, в показанном выше примере, — Вы теряете место, — ибо хранение небольших файлов в файловой системе с большими (чем размер файлов) кластерами приведет к, условно, потери (простою) места на диске.

Говоря проще, отсюда стоит вынести следующее:

• Вы выбираете средний (ни туда, ни сюда) размер кластера, если наверняка не знаете какие файлы у Вас будут храниться на диске, за всеми не уследить и вообще пытаетесь попасть в золотую середину;
• Вы точно знаете, что на диске будут храниться в основном мелкие файлы и выбираете наименьший возможный размер кластера;
• Вам не важен небольшой выигрыш в производительности, ценой потери места и потому выбираете наименьший возможный размер кластера;
• Вы точно знаете, что на диске будут храниться в основном большие файлы и выбираете наибольший доступный размер кластера;
• Вы неиллюзорно важен выигрыш в производительности, ценой потери места и выбираете наибольший доступный размер кластера;
• Вы адепт майкрософт_всё_знает_лучше_меня_зачем_я_читаю_эту_статью и оставляете размер по умочанию.

Но это еще не всё. Для адептов последнего пути, далее приводится набор таблиц, которые используются Miscrosoft по умолчанию, в зависимости от размера носителя, т.е это значения по умолчанию, задаваемые системой. Пользоваться ими или нет, — дело Ваше.

Тип файловой системы

Как уже говорилось, диапазон доступного размера кластера зависит от файловой системы. Узнать её можно, нажав правой кнопкой мыши на диске в проводнике («Мой компьютер»), и выбрав пункт «Свойства».

В соответствующей колонке вы увидите, что за файловая система у Вас выбрана при форматировании для диска или внешнего накопителя (если Вы работаете с ним).

Чтобы узнать текущий размер файла, запустите командную строку («поиск — cmd» или «WIN+R» на клавиатуре — cmd) и введите:

fsutil fsinfo ntfsinfo X:

Результат не заставит себя ждать (не кликабельно):

Двигаемся далее.

В следующей таблице описаны размеры кластера по умолчанию для упомянутой в подзаголовке файловой системы:

Размер томаWindows NT 3.51Windows NT 4.0Windows 10, Windows 8, Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP, Windows 2000

7 МБ — 512 МБ	512 байт	4 КБ	4 КБ
>512 МБ — 1 ГБ	1 КБ	4 КБ	4 КБ
1 GB — 2 GB	2 КБ	4 КБ	4 КБ
2 ГБ — 2 ТБ	4 КБ	4 КБ	4 КБ
2 ТБ — 16 ТБ	Не поддерживается*	Не поддерживается*	4 КБ
16 ТБ — 32 ТБ	Не поддерживается*	Не поддерживается*	8 KB
32 ТБ — 64 ТБ	Не поддерживается*	Не поддерживается*	16 KB
64 TB — 128 TB	Не поддерживается*	Не поддерживается*	32 КБ
128 TB — 256 TB	Не поддерживается*	Не поддерживается*	64 КБ
> 256 ТБ	Не поддерживается	Не поддерживается	Не поддерживается

Звездочка (*) означает, что она не поддерживается из-за ограничений основной загрузочной записи (MBR).

Размер кластера по умолчанию для FAT32

В следующей таблице описаны размеры кластера по умолчанию для упомянутой в подзаголовке файловой системы:

Размер томаWindows NT 3.51Windows NT 4.0Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP, Windows 2000

7 МБ — 16 МБ	Не поддерживается	Не поддерживается	Не поддерживается
16 МБ — 32 МБ	512 байт	512 байт	Не поддерживается
32 МБ — 64 МБ	512 байт	512 байт	512 байт
64 МБ — 128 МБ	1 КБ	1 КБ	1 КБ
128 МБ — 256 МБ	2 КБ	2 КБ	2 КБ
256 МБ — 8 ГБ	4 КБ	4 КБ	4 КБ
8 ГБ — 16 ГБ	8 KB	8 KB	8 KB
16 ГБ — 32 ГБ	16 KB	16 KB	16 KB
32 ГБ — 2 TБ	32 КБ	Не поддерживается	Не поддерживается
> 2 ТБ	Не поддерживается	Не поддерживается	Не поддерживается

Идем далее.

Размер кластера по умолчанию для FAT16

В следующей таблице описаны размеры кластера по умолчанию для упомянутой в подзаголовке файловой системы:

Размер томаWindows NT 3.51Windows NT 4.0Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP, Windows 2000

7 МБ — 8 МБ	Не поддерживается	Не поддерживается	Не поддерживается
8 МБ — 32 МБ	512 байт	512 байт	512 байт
32 МБ -64 МБ	1 КБ	1 КБ	1 КБ
64 МБ — 128 МБ	2 КБ	2 КБ	2 КБ
128 МБ — 256 МБ	4 КБ	4 КБ	4 КБ
256 МБ — 512 МБ	8 KB	8 KB	8 KB
512 МБ -1 ГБ	16 KB	16 KB	16 KB
1 ГБ — 2 ГБ	32 КБ	32 КБ	32 КБ
2 ГБ — 4 ГБ	64 КБ	64 КБ	64 КБ
4 ГБ — 8 ГБ	Не поддерживается	128 КБ *	Не поддерживается
8 ГБ — 16 ГБ	Не поддерживается	256 KB *	Не поддерживается
> 16 ГБ	Не поддерживается	Не поддерживается	Не поддерживается

Звездочка (*) означает, что она доступна только на носителе с размером сектора более 512 байт.

Размер кластера по умолчанию для exFAT

В следующей таблице описаны размеры кластера по умолчанию для упомянутой в подзаголовке файловой системы:

Размер томаWindows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, Windows XP

7 МБ — 256 МБ	4 КБ
256 МБ — 32 ГБ	32 КБ
32 ГБ — 256 ТБ	128 КБ
> 256 ТБ	Не поддерживается

Ну и напоследок послесловие, которое немного резюмирует всё это дело. Еще раз, да.

Послесловие

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

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

С другой, — маловерятно, что на SSD вы храните терабайты фильмов, музыки, фото и других файлов, размером более мегабайта.

Что делать? Как и в случае с файлом подкачки, выбирать решение под свои цели, задачи и железо, либо попросту не заморачиваться, но тогда решительно не понятно зачем Вы это читали 🙂

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

Источник: https://sonikelf.ru/razmer-klastera-i-diskovoe-prostranstvo/

Какой размер кластера выбрать при форматировании: NTFS — FAT32

Приветствую своих читателей и сегодня мне очень приятно перейти от теории поближе к практике. Сегодня мы будем выяснять, какой размер кластера выбрать при форматировании NTFS. Именно НТФС зачастую стоит у большинства пользователей, поэтому коснёмся её. Эта реальная задача постоянно возникает при подготовке жесткого диска к переустановке Windows. А так же в других ситуациях.

Для начала вспомним, что такое кластер и NTFS и какая связь между этими понятиями. Итак, память компьютера (или флешки, или карты памяти) разбивается на отдельные сектора объемом 512 байт или 4 Кб, которые в свою очередь группируются в кластеры. Соответственно, размер кластера кратен объему сектора.

Файловая система среди прочих функций определяет возможный размер кластера:

• В устаревшей FAT32 – это от 1 до 32 Мб;
• Пришедшая ей на смену в USB накопителях exFAT – от 4 до 128 Мб;
• Наиболее стабильная, интересующая нас NTFS – от 4 до 64 Мб;

Размер, имеющий значение

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

Например, мы имеем файл размером 260 Кб и кластеры по 32 Кб. Значит, в 8-и из них будет храниться 32 х 8 = 256 Кб и еще 4 Кб в 9-ом. То есть, в данном случае на диске будет занят объем, соответствующий размеру девяти кластеров 288 Кб, а это уж никак не наши 260 Кб, а на целых 10% больше чем мы предполагали задействовать.

Процент здесь указан просто для иллюстрации того, что не все место диска эффективно используется. Будь у нас файлик поменьше, например 33 Кб (ну, чтоб не помещался в один кластер) это показатель был бы вообще пугающим: 2 кластера по 32 Кб = 64 Кб для хранения 33-ёх!!!

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

1. Выше приведенный пример показывает, что в последнем кластере теоретически может быть использован всего 1 Кб, соответственно, чем больше его размер, тем больше остается незадействованной памяти. Данный эффект усиливается с ростом количества файлов.
   Поэтому вполне логично, что чем меньше размер кластера, тем более эффективно мы сможем использовать носитель информации;
2. С другой стороны. Считывая данные, процессор обращается по адресам каждого из кластеров и это занимает определенное время. Чем больше их задействовано – тем больше таких переходов. Серьезно усугубляет ситуацию и тормозит работу компьютера (особенно в HDD) высокий уровень фрагментации, при которой кластеры не собраны в сплошные блоки, а раскиданы в разных местах. С этой позиции большие кластеры предпочтительнее. Поскольку для размещения условного файла среднего объема их потребуется намного меньше.

Какой размер кластера выбрать — решение принимать вам

Как же все-таки разрешить возникшую дилемму и выбрать оптимальный размер кластера при форматировании NTFS? Да очень просто и здесь есть три варианта:

• Прикинуть, с какими файлами вы собираетесь работать. Если они преимущественно небольшие – можно выбрать размер кластера поменьше. Так же можно разбить диск на несколько разделов и каждый отформатировать со своим размером кластера. Например, установить максимальный для места хранения мультимедийных файлов;
• Установить вместительный жесткий диск с достаточным запасом по объему. И произвести его форматирование, выбрав наибольший размер кластера;
• Вообще не париться по этому поводу и при форматировании установить стандартные настройки по умолчанию. А они напрямую зависят от объема винчестера или SSD;

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

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

Возможно в будущем как-нибудь напишу подробную обзорную статью о том как влияет скорость работы накопителя при разных размерах кластеров.

Кстати, вот ещё одна статья на тему формат-я, гляньте может и это вам интересно: http://profi-user.ru/raznica-formatirovaniya/

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

До скорых встреч в новых темах моего блога.

Источник: http://profi-user.ru/kakoy-razmer-klastera-vybrat-pri-formatirovanii/

Что такое размер кластера жёсткого диска, и как его изменить без форматирования раздела

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

1. Что такое кластер дискового пространства

Кластер – это логическая единица дискового пространства, минимальный его блок, выделяемый для записи файла. У жёстких дисков есть физическая единица дискового пространства – сектор. Сектора могут быть размером 512 или 4096 байт.

Это предустановленный производителем жёсткого диска параметр, и он не может быть изменён программными средствами. Последние могут оперировать только логической единицей – кластером. И оперировать только в рамках возможностей выбранной файловой системы.

К примеру, для NTFS размер кластера может быть установлен от 512 байт до 2 Мб (2048 Кб).

Размер кластера, отличный от предлагаемого по умолчанию, мы можем выбрать при форматировании раздела средствами Windows.

Размер кластера также можем выбрать по своему усмотрению при создании разделов в штатном управлении дисками. Создаём том (раздел).

Указываем размер тома.

Идём далее.

И на этапе форматирования тома выбираем размер кластера.

Итак, кластер – это единичный блок для размещения файлов. Каждый файл записывается в новый кластер. Файл весом более размера кластера, соответственно, занимает несколько таковых. Чем меньше размер кластера, тем более эффективно будет расходоваться место на диске при условии, что на нём преимущественно хранятся мелкие файлы до 512, 1024, 2048 байт и т.д.

Тогда как при кластере большего размера дисковое пространство будет менее эффективно занято данными с малым весом. Но вопрос об эффективности не будет стоять при условии хранения на диске данных с весом от 64 Кб или иного выбранного размера. При этом ещё и получаем незначительный прирост производительности в скорости чтения и записи HDD в условиях фрагментации.

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

2. Насколько значителен прирост производительности при большем размере кластера

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

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

3. Какой размер кластера для каких целей лучше

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

Он по умолчанию задаётся 4096 байт (4 Кб). И является оптимальным выбором для системного раздела С, поскольку в состав системы и сторонних программ входит огромное множество мелковесных файлов. Изменять его не рекомендуется.

А вот с несистемными разделами можно поэкспериментировать. Но прежде необходимо оценить текущую ситуацию и узнать, какой размер кластера у раздела сейчас. Чтобы потом сделать выводы о приросте производительности.

4. Как узнать размер кластера

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

В неё вводим команду по типу:

fsutil fsinfo ntfsinfo C:

Где вместо C в конце подставляем букву нужного раздела. И смотрим графу «Байт на кластер».

5. Как изменить размер кластера

Как упоминалось в первом пункте статьи, для изменения размера кластера необходимо либо отформатировать раздел, либо удалить его и создать заново. Хоть средствами Windows, хоть сторонним софтом для работы с дисками от Acronis, AOME, Paragon и т.п. Если на разделе имеются данные, их можно временно перенести на другой раздел, другое устройство информации или в облако на крайний случай. И это будет самый правильный вариант.

Изменение размера кластера раздела с имеющимися данными без их временного переноса в другое место – это потенциально рисковая операция. Рисковая операция – во-первых.

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

5.1. MiniTool Partition Wizard

В любой из коммерческих редакций MiniTool Partition Wizard можем изменить размер кластера без форматирования и пересоздания раздела, с сохранностью данных. Кликаем в окне программы нужный раздел, выбираем функцию изменения кластера.

Смотрим, какой у нас текущий размер. И в выпадающем списке выбираем новый. Затем жмём «Да».

Штатные средства Windows при задании размера кластера предусматривают выбор их показателей в байтах, килобайтах и в случае с Win10 в мегабайтах. Сторонние программы могут предусматривать выбор показателей в иной метрике – в секторах на кластер. Это число в степени двойки. Как ориентироваться? Просто делим на 2. Если хотим выбрать размер кластера, скажем, 64 Мб, указываем число 128. Если 32 Кб, выбираем число 64. Если 16 Кб – 32. И так далее по этому же принципу.

В главном окне MiniTool Partition Wizard применяем операцию и ожидаем её завершения.

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

5.2. Acronis Disk Director

Платный Acronis Disk Director, мастодонт на рынке ПО для оперирования дисковым пространством, также предусматривает возможность изменения размера кластера без потери данных. В окне программы выбираем нужный раздел, кликаем соответствующую операцию.

Смотрим, какой сейчас у раздела размер кластера. И из выпадающего перечня выбираем новый.

Применяем операцию.

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

Источник: https://www.white-windows.ru/chto-takoe-razmer-klastera-zhyostkogo-diska-i-kak-ego-izmenit-bez-formatirovaniya-razdela/

Почему не нужен TRIM в серверах

Для начала стоит разобраться с тем, как работает SSD, что такое сборка мусора, как работает TRIM и главное — почему он не нужен в серверах.
SSD отличается от HDD не только ограниченным ресурсом ячеек. Есть еще множество архитектурных особенностей.

Размеры секторов

Стандартный размер сектора для большинства блочных устройств (жестких дисков и систем хранения данных) равен 512 байт (на некоторых SAS/SCSI дисках возможны 520/528 байт для дополнительного контроля целостности данных). Последние несколько индустрия пытается перейти на секторы 4096 байт (4 КиБ), т.н. Advanced Format.

Продвигается процесс медленно, все пока что остановилось на 512e, т.е. дисках с 4K-секторами внутри, но с эмуляцией 512 байт секторов для хоста. На дисках 512e могут возникать проблемы с производительностью: при необходимости записать блок данных размером меньше 4 КиБ контроллеру диска приходится считывать сектор, менять в нем данные и только потом записывать обратно.

Для SSD ситуация с записью небольших блоков еще сложнее:

Контроллер SSD по-прежнему вынужден прикидываться блочным устройством с 512 байт сектором. Но внутри все сложнее: ячейки объединены в страницы размером, как правило, 4-8 КиБ, т.е. это минимально доступный для чтения или записи объем.

минимально доступный для стирания блок может оказаться размером, например, в 512 КиБ.

Write amplification (усиление записи)

Данный термин означает соотношение между объемом данных, который фактически приходится записывать на флеш-память, и объемом, который пишет хост. Предположим, что у нас есть блок 512 КиБ с данными и нужно поменять небольшой фрагмент. Для модификации сектора в 512 байт контроллеру SSD приходится делать несколько операций (ситуация напоминает write penalty для RAID-5/6):

• прочитать весь блок в буфер
• модифицировать содержимое буфера
• стереть весь блок
• записать новое содержимое буфера

Т.е. для размера транзакции в 512 байт на SSD с размером блока страниц в 512 КиБ получаем write amplification = 1024 раза. Это не самым лучшим образом сказывается а) на производительности и б) ресурсе, который по-прежнему составляет несколько тысяч циклов перезаписи для MLC SSD.

Copy on write

Проблема усиления записи имеет простое решение: нужно стараться записывать данные в уже предварительно стертые блоки. На помощь приходит классический алгоритм copy-on-write, разновидности которого используются для оптимизации записи в RAID-DP у Netapp или в ZFS (только слоем выше — на уровне файловой системы).

Суть алгоритм copy-on-write заключается в записи в «выгодные» участки носителя, т.е. в случае SSD — на чистые (стертые) блоки. В нижеприведенном примере модифицируется содержимое страницы «B». Вместо чтения/стирания/записи всего большого блока достаточно лишь прочитать содержимое страницы, модифицировать ее и записать в другое место. При этом необходимо поменять указатель, чтобы те же LBA указывали на новое физическое место размещения данных.

В качестве дополнительного средства борьбы с write amplification большинство современных контроллеров SSD используют сжатие данных.

Где взять чистые блоки?

На новом SSD все блоки являются чистыми и готовыми к записи. Дальше есть резервная область, которая на самом деле, используется всегда, так как помимо оптимизации записи необходимо обеспечить еще и равномерность износа ячеек SSD.

TRIM

Как быть, если после непрерывной записи чистых блоков уже не осталось? Для можно каким-либо образом узнать, где на SSD находятся пользовательские данные, а где размещены невалидные данные, оставшиеся после удаления файлов. Собственно, этим и занимается TRIM.

SSD, как и любое другое блочное устройство, ничего не знает, о том, какие именно данные на нем хранятся. ОС может взаимодействовать как со слоем файловой системы, так и с блочным устройством, т.е. после удаления файла ОС передает на SSD вместе с командой TRIM (или UNMAP для SCSI) список LBA, по которым находились удаленные данные.

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

Background garbage collection (фоновая сборка мусора)

Второй очевидный способ обнаружения невалидных данных — повторные запросы на запись от хоста по тем же LBA. Для хоста это выглядит, как перезапись одних и тех же секторов, но SSD все время старается писать в разные блоки. В вышеприведенной иллюстрации работы copy-on-write актуальные данные содержатся в новой странице «B’», после чего в исходной странице остаются невалидные данные.

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

Собственно, за все это и отвечает сборка мусора.

«Правильные» SSD, рассчитанные на интенсивную запись, имеют достаточный over-provisiong (резервную область) в качестве «пространства для маневра» и эффективный контроллер с достаточным объемом кэша (разумеется, защищенного конденсаторами) для размещения метаданных и буферизации чтения/записи.

Если контроллер не успевает быстро подготовить место для быстрой записи, то это неминуемо отразится на производительности, будет периодический рост задержек в несколько раз относительно среднего значения, как на данной картинке с www.storagereview.com:

TRIM и реальность

Для работы TRIM помимо выполнения множества условий (поддержка со стороны ОС и файловой системы) необходимо разобраться с другими слоями абстракции, например, RAID.

Пересчитать адреса пришедшие на с TRIM на контроллер от хоста и раскидать их по отдельным дискам теоретически возможно, но никто (ни LSI, ниAdaptec by PMC) не торопится с реализацией.

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

• Виртуализация. На физическом диске или томе RAID-контроллера лежит одна файловая система (VMFS/NTFS/XFS), а на ней — виртуальный диск в виде файла (который никуда не удаляется и даже не меняется в размере, если диск не тонкий), а внутри виртуального диска — другая ФС. Как, от кого и кому передавать TRIM в такой ситуации — совершенно непонятно.
• Предоставление блочного доступа. Это добавляет несколько уровней абстракции. Том->Раздел (или ФС + файл)->Таргет->Файловая система
• Файловый доступ. В организациях, как правило, никто не удаляет регулярно большое количество файлов. Такой сценарий встречается разве что при хранении временного медиа-контента, например, при рендеринге или перекодировании видео, а SSD тут совершенно не нужны. Файл-сервер обычно используется для долговременного хранения информации.
• Базы данных. Файл, который, опять-таки не удаляется, а лишь модифицируется и растет.

Заключение

Используйте совместимые с вашим контроллером SSD, выбирайте их с учетом ожидаемой нагрузки на запись и не волнуйтесь о TRIM.

Источник: https://www.truesystem.ru/review/360101/