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

Обновлено: 21.11.2024

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

Что такое блочное хранилище?

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

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

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

Блокирование, объектное или файловое хранилище

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

Хранилище объектов

Объектное хранилище, также известное как объектное хранилище, разбивает файлы данных на части, называемые объектами. Затем он сохраняет эти объекты в одном репозитории, который может быть распределен по нескольким сетевым системам.

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

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

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

Для получения дополнительной информации об объектном хранилище ознакомьтесь с документом "Объектное хранилище: полное руководство" и нашим видео "Что такое объектное хранилище?"

IBM Cloud Object Storage: создано для бизнеса (04:10)

Хранение файлов

Хранилище файлов, также называемое файловым хранилищем или хранилищем на основе файлов, обычно связано с технологией сетевого хранилища (NAS). NAS предоставляет хранилище пользователям и приложениям, используя ту же идеологию, что и традиционная сетевая файловая система. Другими словами, пользователь или приложение получает данные через деревья каталогов, папки и отдельные файлы. Это работает аналогично локальному жесткому диску. Однако NAS или сетевая операционная система (NOS) управляют правами доступа, общим доступом к файлам, блокировкой файлов и другими элементами управления.

Хранилище файлов может быть очень простым в настройке, но доступ к данным ограничен одним путем к данным, что может повлиять на производительность по сравнению с блочным или объектным хранилищем. Хранилище файлов также работает только с распространенными протоколами файлового уровня, такими как файловая система новой технологии (NTFS) для Windows или сетевая файловая система (NFS) для Linux. Это может ограничить удобство использования в разных системах.

Более подробные сведения о хранении файлов см. в статье "Хранение файлов: полное руководство".

В следующем видео Эми Блеа дает обзор различных типов хранилищ и вариантов их использования:

Блочное хранилище и файловое хранилище (04:03)

Примеры

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

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

Чтобы узнать больше о виртуальных машинах, см. «Виртуальные машины: полное руководство».

Развертывание в частном облаке — еще один отличный вариант использования блочного хранилища. Для более глубокого изучения частных облаков и блочного хранилища ознакомьтесь с пояснением IBM Garage о виртуализации для расширения виртуализированного частного облака с помощью блочного и файлового хранилища.

Блочное хранилище и контейнеры

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

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

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

Подробный обзор контейнеров и контейнеризации см. в разделах «Контейнеры: полное руководство» и «Контейнеризация: полное руководство».

Сети хранения данных

Разработчики часто развертывают блочное хранилище с помощью сети хранения данных (SAN). SAN — это компьютерная сеть, обеспечивающая доступ к хранилищу данных. SAN предоставляют блочное хранилище другим сетевым системам, как если бы эти блоки были локально подключенными устройствами. Например, сервер может подключиться к SAN с помощью подключения к сети передачи данных, такой как Fibre Channel, интерфейс малых компьютерных систем Интернета (iSCSI) или Infiniband, для доступа к блоку, как если бы это был том с локальным доступом. Вы также можете настроить несколько массивов хранения в SAN и подключить к SAN несколько серверов.

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

Загрузите «Введение в сети хранения данных», чтобы получить дополнительную информацию о технологии SAN.

RAID-массивы

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

Подробнее о технологии RAID см. в разделе "Дисковые массивы".

Открытый код

Альтернативы с открытым исходным кодом традиционным решениям SAN, ориентированным на поставщиков, находятся на подъеме: новые проекты появляются почти ежедневно, в то время как существующие проекты продолжают улучшаться и добавлять функции. Проект с открытым исходным кодом FreeNAS предлагает как блочное хранилище, так и программно-определяемый RAID; Openfiler — еще одно решение для хранения данных с открытым исходным кодом, включающее поддержку блочного хранилища и RAID.

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

Блокировать хранилище как услугу

Блочное хранилище как услуга (BSSaaS) относится к гораздо более широкой категории корпоративного хранилища как услуги (ESaaS), где те, кто ищет облачное хранилище, могут выбрать блочное, файловое или объектное хранилище для поддержки своего хранилища данных. потребности. По большей части при работе с ESaaS пользователям также придется выбирать решение IaaS или PaaS и развертывать приложения и серверы непосредственно в облаке.

Как масштабировать блочное хранилище

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

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

Блочное хранилище и IBM

IBM Cloud Block Storage стремится помочь партнерам, предприятиям и организациям удовлетворить их потребности в блочных хранилищах, предлагая производительность локального диска с поддержкой флэш-памяти, устойчивость и надежность SAN, настраиваемые IOP и предсказуемую оплату.

В новых жестких дисках размер сектора (наименьшая единица данных, которую вы можете физически прочитать или записать на диск) увеличен с 512 до 4096 байт. Это необходимо для разрешения дисков размером более 2 терабайт. Можно эмулировать старый размер сектора, но с потерей производительности. Системы Linux и Mac уже оптимизированы для большего размера сектора, но Windows 7 — это система Microsoft с наилучшей поддержкой.

Между тем, твердотельные накопители имеют физическую единицу измерения 512 КБ (полмегабайта). Это наименьший блок данных, который вы можете стереть, и вы должны стереть данные, прежде чем сможете их перезаписать. Это создает другую проблему размера блока для ОС, файловой системы и приложения.

Новые большие жесткие диски

Первый жесткий диск компьютера на PC XT в 1983 году содержал 10 мегабайт данных, отформатированных в секторах по 512 байт. Сегодня на жестком диске может быть в 100 000 раз больше места для хранения, но поскольку компьютерные системы ничего не меняют до тех пор, пока в этом нет необходимости, диски по-прежнему хранят данные в блоках по 512 байт. Это означает, что на самом деле все, что вы читаете или записываете на диск, округляется до размера одной или нескольких предварительно отформатированных областей размером 512 байт на поверхности диска.

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

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

Самое большое число, которое можно сохранить в 32-битном формате, составляет 4 гигабайта. Если это число является номером сектора, это означает, что максимальное количество секторов, которые вы можете адресовать на жестком диске с 32-битным числом, составляет 2 терабайта. Теперь доступны диски, содержащие 2 терабайта данных, и в разработке находятся диски большего размера. Поэтому для таких больших дисков требуется новый размер сектора.

Все большее количество современных дисков имеют размер физического сектора 4096 байт. Они могут делать вид, что у них 512-байтовые сектора для совместимости, но это неэффективно.

Программа записывает 512 байт данных в файл на диске.

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

Теперь, если на диске есть собственные сектора размером 512 байт, данные записываются, и операция завершается. Общее время: 12 миллисекунд.
Однако, если диск имеет сектора размером 4096 байт и эмулирует только размер сектора 512, контроллер должен считать с диска 4096 байт, заменить 512 байтов внутри большего блока и теперь ждать один полный оборот или около 8,3 дополнительных миллисекунд, чтобы данные прошли весь путь, прежде чем весь блок можно будет перезаписать на диск. Общее время: 20,3 миллисекунды.

Конечно, если программа всегда записывает 4096 страниц или система заставляет программы записывать страницы целиком (как это делают Unix, Linux и Mac), то эта проблема никогда не возникает. Также не проблема, если драйверы устройств были обновлены для буферизации данных и принудительного увеличения размера блока, как это происходит в Windows 7. Только старые системы, такие как XP, могут столкнуться с проблемами.

Твердотельные накопители

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

Твердотельный накопитель записывает данные, как в игрушке, где ребенок нажимает на пластиковый лист, чтобы рисовать линии, а затем стирает всю страницу, поднимая пластиковый лист вверх. SSD может стереть полмегабайта данных, обнулив всю область. Затем он может записывать 1 в отдельные байты памяти. Он всегда может превратить отдельный 0 в 1, но может только стереть весь блок размером 512 КБ обратно в 0.

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

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

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

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

Твердотельные накопители и жесткие диски примерно сопоставимы для больших последовательных файлов. Жесткий диск может читать последовательно без задержки поиска или задержки вращения. Учитывая высокую стоимость хранилища SSD в наши дни, вероятно, лучше поместить файл подкачки на жесткий диск, потому что страницы крадут и записывают на диск блоками по 4 КБ. Файл гибернации записывается и читается последовательно. Если вы сможете поместить эти файлы на SSD, они, вероятно, будут работать немного быстрее, но они большие, и вы можете найти что-то более подходящее для этих гигабайт.

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

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

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

14. 3.1.1. Архитектура дисковода¶

Жесткий диск состоит из одной или нескольких круглых пластин, установленных друг на друга и прикрепленных к центральному шпинделю. Диски вращаются непрерывно с постоянной скоростью. Каждой пригодной для использования поверхности каждой пластины назначается головка чтения/записи или головка ввода-вывода, через которую данные считываются или записываются, что-то вроде устройства руки фонографа, «читающего» звук с грампластинки. В отличие от иглы фонографа, головка чтения/записи диска фактически не касается поверхности жесткого диска. Вместо этого он остается немного выше поверхности, и любой контакт при нормальной работе может привести к повреждению диска. Это расстояние очень мало, намного меньше высоты пылинки. Это можно сравнить с 5000-километровым перелетом на самолете через Соединенные Штаты, причем самолет летит на высоте одного метра!

Жесткий диск обычно имеет несколько пластин и несколько головок чтения/записи, как показано на рис. 14.3.1 (a).Каждая головка прикреплена к рычагу, который соединяется со стрелой. 1 Стрела одновременно перемещает все головки внутрь или наружу. Когда головки находятся в некотором положении над дисками, данные на каждом диске доступны непосредственно для каждой головки. Данные на одной пластине, доступные для любого положения головки этой пластины, в совокупности называются дорожкой, то есть все данные на пластине, находящиеся на фиксированном расстоянии от шпинделя, как показано на рис. 14.3.1 ( б). Совокупность всех дорожек, находящихся на фиксированном расстоянии от шпинделя, называется цилиндром. Таким образом, цилиндр — это все данные, которые можно прочитать, когда рычаги находятся в определенном положении.

Рисунок 14.3.1: Схема дисковода. (a) Типичный дисковод, уложенный в виде стопки пластин. (b) Одна дорожка на пластине дисковода. ¶

Каждая дорожка разделена на секторы. Между каждым сектором есть межсекторальные промежутки, в которых данные не хранятся. Эти промежутки позволяют считывающей головке распознавать конец сектора. Обратите внимание, что каждый сектор содержит одинаковое количество данных. Поскольку внешние дорожки имеют большую длину, они содержат меньше битов на дюйм, чем внутренние дорожки. Таким образом, около половины потенциального пространства для хранения тратится впустую, потому что только самые внутренние дорожки хранятся с максимально возможной плотностью данных. Это расположение показано на рис. 14.3.2 (а). Дисковые накопители сегодня фактически группируют дорожки в зоны, так что дорожки в самой внутренней зоне регулируют свою плотность данных на выходе, чтобы поддерживать ту же радиальную плотность данных, затем дорожки следующей зоны сбрасывают плотность данных, чтобы лучше использовать их способность хранения, и так далее. Такое расположение показано на рис. 14.3.2 (b).

Рисунок 14.3.2: Организация дисковой пластины. Точки указывают на плотность информации. (а) Номинальное расположение дорожек, показывающее уменьшение плотности данных при движении наружу от центра диска. (b) «зональное» расположение с периодическим сбросом размера и плотности сектора в дорожках дальше от центра. ¶

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

При чтении определенного байта или серии байтов данных с жесткого диска выполняются три отдельных шага. Во-первых, головка ввода-вывода перемещается так, чтобы располагаться над дорожкой, содержащей данные. Это движение называется поиском. Во-вторых, сектор, содержащий данные, поворачивается, чтобы попасть под головку. При использовании диск всегда вращается. На момент написания этой статьи типичная скорость вращения диска составляла 7200 оборотов в минуту (об/мин). Время, затраченное на ожидание того, что желаемый сектор попадет под головку ввода-вывода, называется ротационной задержкой или ротационной задержкой. Третий шаг — фактическая передача (т. е. чтение или запись) данных. Когда первый байт помещается под головку ввода-вывода, требуется относительно мало времени для чтения информации, просто количество времени, необходимое для того, чтобы все это переместилось под головку. На самом деле дисководы предназначены не для чтения одного байта данных, а для чтения целого сектора данных при каждом запросе. Таким образом, сектор – это минимальный объем данных, который можно прочитать или записать за один раз.

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

Время поиска медленное (обычно это самая затратная часть операции ввода-вывода) и

Если прочитан один сектор файла, следующий сектор, вероятно, скоро будет прочитан.

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

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

В системах Microsoft Windows существует специальная часть диска, называемая таблицей размещения файлов, в которой хранится информация о том, какие секторы принадлежат какому файлу. Напротив, Unix не использует кластеры. Наименьшая единица размещения файла и наименьшая единица, которая может быть прочитана/записана, — это сектор, который в терминологии Unix называется блоком.Unix хранит информацию об организации файлов в определенных блоках диска, называемых индексными дескрипторами.

Группа физически смежных кластеров из одного файла называется экстентом. В идеале все кластеры, составляющие файл, должны располагаться на диске непрерывно (т. е. файл будет состоять из одного экстента), чтобы свести к минимуму время поиска, необходимое для доступа к различным частям файла. Если диск почти заполнен, когда создается файл, может не быть доступного экстента, достаточного для хранения нового файла. Кроме того, если файл растет, физически рядом с ним может не оказаться свободного места. Таким образом, файл может состоять из нескольких экстентов, широко разнесенных по диску. Чем полнее диск и чем больше файлов на нем изменяются, тем сильнее становится фрагментация файлов (и, как следствие, время поиска). Фрагментация файлов приводит к заметному снижению производительности, поскольку для доступа к данным требуются дополнительные операции поиска.

Другой тип проблем возникает, когда размер логической записи файла не соответствует размеру сектора. Если размер сектора не кратен размеру записи (или наоборот), записи не будут равномерно помещаться в секторе. Например, сектор может иметь длину 2048 байт, а логическая запись — 100 байт. Это оставляет место для хранения 20 записей с оставшимися 48 байтами. Либо дополнительное пространство тратится впустую, либо записи могут пересекать границы сектора. Если запись пересекает границу сектора, для ее чтения может потребоваться два обращения к диску. Если вместо этого пространство остается пустым, такое неиспользуемое пространство называется внутренней фрагментацией .

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

Каждая организация дисков требует, чтобы часть дискового пространства использовалась для организации секторов, кластеров и т. д. Расположение секторов внутри дорожки показано на рис. 14.3.3. Типичная информация, которая должна храниться на самом диске, включает в себя таблицу размещения файлов, заголовки секторов, которые содержат адресные метки и информацию о состоянии (независимо от того, используется он или нет) для каждого сектора, а также промежутки между секторами. Заголовок сектора также содержит коды обнаружения ошибок, помогающие убедиться, что данные не повреждены. Вот почему большинство дисков имеют «номинальный» размер, превышающий фактический объем пользовательских данных, которые могут храниться на диске. Разница заключается в количестве места, необходимого для организации информации на диске. Еще больше места будет потеряно из-за фрагментации.

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

14. 3.1.2. Стоимость доступа к диску¶

Когда требуется поиск, обычно это основная стоимость доступа к информации на диске. Это предполагает, конечно, что поиск необходим. При чтении файла в последовательном порядке (если секторы, составляющие файл, расположены на диске непрерывно), требуется небольшой поиск. Однако при доступе к произвольному сектору диска время поиска становится доминирующей стоимостью доступа к данным. Хотя фактическое время поиска сильно варьируется, в зависимости от расстояния между дорожкой, на которой в данный момент находится головка ввода-вывода, и дорожкой, на которую перемещается головка, мы будем рассматривать только два числа. Одним из них является стоимость перехода от одной дорожки к другой или минимальное время, необходимое для перехода с одной дорожки на соседнюю дорожку. Это подходит, когда вы хотите проанализировать время доступа к файлам, которые хорошо расположены на диске. Второе число — это среднее время поиска для случайного доступа. Эти два числа часто предоставляются производителями дисков. Типичным примером является накопитель Western Digital Caviar с последовательным интерфейсом ATA. В спецификациях производителя указано, что время от дорожки к дорожке составляет 2,0 мс, а среднее время поиска — 9,0 мс. В 2008 году типичный диск этой линейки может иметь размер 120 ГБ. В 2011 году та же линейка накопителей имела размеры до 2 или 3 ТБ. В оба года заявленное среднее время поиска и переход от одной дорожки к другой были одинаковыми.

В течение многих лет типичная скорость вращения жестких дисков составляла 3600 об/мин, или один оборот каждые 16,7 мс. Большинство дисковых накопителей в 2011 году имели скорость вращения 7200 об/мин, или 8,3 мс на оборот. При случайном чтении сектора вы можете ожидать, что диск должен будет повернуться наполовину, чтобы нужный сектор оказался под головкой ввода-вывода, или 4.2 мс для диска на 7200 об/мин.

Оказавшись под головкой ввода-вывода, сектор данных может быть передан с той же скоростью, с которой этот сектор вращается под головкой. Если нужно прочитать всю дорожку, то потребуется один оборот (8,3 мс при 7200 об/мин), чтобы переместить всю дорожку под головку. Если нужно прочитать только часть трека, то потребуется пропорционально меньше времени. Например, если на дорожке 16 000 секторов и один из них нужно прочитать, это потребует тривиального времени (1/16 000 оборота).

Предположим, что старый жесткий диск имеет общую (номинальную) емкость 16,8 ГБ, распределенную по 10 пластинам, что дает 1,68 ГБ на каждую пластину. Каждая пластина содержит 13 085 дорожек, и каждая дорожка содержит (после форматирования) 256 секторов по 512 байт/сектор. Время поиска между дорожками составляет 2,2 мс, а среднее время поиска для произвольного доступа — 9,5 мс. Предположим, что операционная система поддерживает размер кластера 8 секторов на кластер (4 КБ), что дает 32 кластера на дорожку. Скорость вращения диска составляет 5400 об/мин (11,1 мс на оборот). На основе этой информации мы можем оценить стоимость различных операций по обработке файлов.

Сколько времени требуется для прочтения трека? В среднем потребуется половина оборота, чтобы подвести первый сектор дорожки под головку ввода-вывода, а затем один полный оборот, чтобы прочитать дорожку.

Сколько времени потребуется для чтения файла размером 1 МБ, разделенного на 2048 записей размером в один сектор (512 байт)? Этот файл будет храниться в 256 кластерах, потому что каждый кластер содержит 8 секторов. Ответ на вопрос во многом зависит от того, как файл хранится на диске, то есть весь ли он вместе или разбит на несколько экстентов. Мы рассчитаем оба случая, чтобы увидеть, насколько велика разница.

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

В этом уравнении 9,5 мс. среднее время поиска (случайной) дорожки на диске. 11,1 мс. это время одного оборота диска, вращающегося со скоростью 5400 об/мин. Поскольку нам нужно дождаться задержки вращения (половина оборота), а затем прочитать все содержимое дорожки (один полный оборот), мы умножаем 11,1 мс. на 1,5. Таким образом, общее время чтения случайной дорожки с диска составляет 26,2 мс.

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

Здесь 2,2 мс. время поиска соседней дорожки. Опять же, мы должны дождаться задержки вращения (половина оборота), за которой следует полный оборот, чтобы прочитать дорожку, поэтому мы умножаем время вращения (11,1 мс) на 1,5 для оборота диска. Таким образом, мы получаем в сумме 18,9 мс. для чтения данных с соседней дорожки.

Поэтому общее время, необходимое для чтения всех 8 соседних дорожек, равно

Наоборот, сколько времени будет, если кластеры файла будут случайным образом распределены по диску? Затем мы должны выполнить поиск для каждого кластера, за которым следует время задержки вращения. Как только первый сектор кластера попадает под головку ввода-вывода, для чтения кластера требуется очень мало времени, потому что только 8/256 дорожки должны вращаться под головкой, а общее время задержки составляет около 5,9 мс. Время Читать. Таким образом, общее требуемое время составляет около

или около 4 секунд. Это намного больше времени, необходимого, когда файл целиком находится на диске! То есть 256 раз мы должны выполнить поиск случайной дорожки (9,5 мс.). Затем мы ждем в среднем половину оборота диска, после чего считываем фактические данные, что требует еще 8/256 оборота, что в сумме составляет 5,9 мс.

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

14. 3.1.3. Примечания¶

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

Что еще больше усложняет ситуацию, так это то, что твердотельные накопители (SSD) работают несколько иначе.

Различия между чанком, страницей, блоком, сектором и байтами/битами в
системах хранения?
Все они основаны друг на друге.

Бит — это наименьшая единица данных, буквально 0/1 (также известный как включение/выключение, также известный как да/нет, также известный как истина/ложь). В настоящее время все цифровые данные существуют в виде битов в том или ином физическом формате (магниты, электрические импульсы, свет и т. д.). Обозначается буквой «b» (маленькая b).

Байт – это наиболее часто используемая комбинация битов. Один байт равен 8 битам. Обозначается буквой «В» (большая Б). Один байт может представлять $2^8$ (256) разных значений. Наиболее распространенным примером является набор символов ASCII, который присваивает большинству цифр/букв/символов некоторые числа от 0 до 127. Например, заглавная буква A («A») — это код ASCII 65. Числа 128 и выше различаются символами. набор и обычно содержат различные специальные символы, такие как латинские буквы.

Сектор

Сектор – это физическое место на отформатированном диске, содержащее информацию. При форматировании диска определяются дорожки (концентрические кольца от внутренней части диска к внешней). Каждая дорожка делится на слайс, который является сектором. На жестких дисках и дискетах каждый сектор может содержать 512 байт данных.
Блок, с другой стороны, представляет собой группу секторов, к которым операционная система может обращаться (указывать). Блок может состоять из одного сектора или нескольких секторов (2,4,8 или даже 16) Чем больше диск, тем больше секторов будет вмещать блок.

Заблокировать

Блок, с другой стороны, – это группа секторов, к которым операционная система может обращаться (указывать). Блок может состоять из одного сектора или из нескольких секторов (2,4,8 или даже 16). Чем больше диск, тем больше секторов будет содержать блок. Блок — это абстракция, представляющая наименьшую единицу хранения в файловой системе. Внутри ядра все операции с файловой системой происходят в терминах блоков. Блок в контексте хранилища — это наименьший размер, с которым вы можете взаимодействовать с оборудованием. Всякий раз, когда вы читаете с диска или записываете на диск, вы читаете столько раз, сколько блоков вам нужно прочитать. Размер блока NTFS по умолчанию (размер кластера AKA, единица распределения AKA) составляет 4096 байт (4 КБ). Если у вас есть файл длиной ровно 4096 байт, то вы читаете один блок с диска. Если это 4097 байт, то вы читаете два блока. Вы не можете прочитать частичный блок, поэтому, даже если файл на самом деле не использует весь блок, файловая система хранилища очистит остальную часть блока. Простой способ увидеть это в действии — создать пустой текстовый файл на жестком диске, посмотреть свойства и разницу между «Размером» (0 байт) и «Размером на диске» (4096 байт).

Почему тогда блоки? Почему операционная система не указывает прямо на сектора? Потому что существуют ограничения на количество блоков или адресов дисков, которые может адресовать операционная система. Определяя блок как несколько секторов, ОС может работать с большими жесткими дисками без увеличения количества адресов блоков. Например, PC DOS (по крайней мере, более ранние версии) могла адресовать только 65 536 блоков (64 КБ), и каждый блок мог быть только одним сектором. Таким образом, максимальный размер тома диска составлял 32 МБ (64 КБ 512 байт). (Более ранние версии Mac OS имели ограничение объема 16 МБ по тем же причинам). Если вы увеличите размер блока, скажем, до 4 КБ, та же версия DOS теперь сможет работать с томами размером до 256 МБ (64 КБ адресов блоков по 4 КБ).
С текущими версиями ОС, программное обеспечение для форматирования рассмотрит размер диска и определит наименьшее количество секторов, которые должны быть в блоке, чтобы можно было использовать весь диск. Итак, когда вы форматируете дискету, размер блока будет равен одному сектору. Например, при форматировании диска объемом 230 МБ размер блока составляет 8 секторов (4 КБ). Почему это важно?

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

ИСТИНА. Хотя размер файла будет таким же, для его хранения будет использоваться меньше секторов. И наоборот, когда файл копируется с гибкого диска на жесткий диск, он обычно занимает больше места на диске. Когда файлы хранятся на диске, они всегда занимают целое число блоков. Любое ненужное пространство в конце блока не используется и тратится впустую. Например, предположим, что размер блока вашего жесткого диска составляет 4 КБ, а у вас есть файл размером 4,5 КБ. Для этого требуется 8 КБ для хранения на жестком диске (2 целых блока), но только 4,5 КБ на дискете (9 блоков размером с дискету).
Разная информация… Если вы склонны хранить много маленьких файлов на жестком диске (например, запуск Windows и Windows-приложений), в блоках, используемых для хранения всех этих маленьких файлов, может быть
много неиспользуемого пространства.Точно так же сжатие большого количества маленьких файлов может не сэкономить столько места на большом жестком диске с большим размером блока. Если размер блока равен 4 КБ, а вы сжимаете файл размером 3 КБ, файл будет сжат, но по-прежнему будет занимать 4 КБ дискового пространства. Если вы выполняете «Получить информацию» о файле на Mac, в информации о размере будет указано что-то вроде «12 КБ на диске, использовано 8320 байт». 12 КБ — это объем используемого дискового пространства в зависимости от размера блока. Таким образом, если размер блока вашего диска составляет 4 КБ, это число всегда будет увеличиваться с шагом 4 КБ. 8320 байт - это реальный размер файла. Обратите внимание, что вам нужно перейти к Get Info, чтобы увидеть фактический размер файла. Этот номер не отображается в режиме просмотра по имени.

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

Определение размера блока в ОС — это компромисс. Каждый файл должен занимать как минимум один блок, даже если файл имеет длину 0 байт, чтобы было к чему прикрепить метаданные файла. Если вы не можете гарантировать, что ваши файлы ВСЕГДА будут кратны размеру блока (например, в ОС с блоком 4 КБ все файлы имеют размер 4 КБ), будет определенное количество потерь для файлов, которые точно не вписываются в размер. этот блок.

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

С другой стороны, большие блоки означают меньше метаданных, но также означают большие потери при хранении небольших файлов. например файл размером 1 байт, хранящийся в блоке размером 4 КБ, занимает 3,99 КБ этого блока.

Каждому из этих блоков ОС должна присвоить идентификационный номер, чтобы его можно было однозначно идентифицировать. ОС, использующая 8-битное поле идентификатора, может отслеживать только 256 блоков и, следовательно, только 256 файлов. Но если каждый из этих блоков на самом деле имеет размер 1 мегабайт, вы можете хранить до 256 мегабайт данных.

Однако, как обсуждалось ранее, маленькие блоки означают больше метаданных. Теперь, когда размеры дисков находятся в диапазоне 3+ терабайт, с блоками по 512 байт, вам нужно было иметь хранилище метаданных для 3 ТБ / 512 байт = 6,44 миллиарда блоков. Это одна из основных потерь пространства. Так что теперь они поставляют диски с блоками по 4 КБ, что в 8 раз больше, поэтому вам нужно хранилище метаданных только для 805 миллионов блоков. Общее количество возможных файлов было сокращено в 8 раз, но уменьшенный объем метаданных означает, что вы можете хранить больше полезных данных.

Кстати, 6,4 млрд блоков – это больше, чем может напрямую адресовать 32-разрядная система. 2 ^ 32 имеет верхний предел ~ 4,2 миллиарда, поэтому старые 32-разрядные машины не могли использовать весь диск емкостью 3 ТБ. Следовательно, переход на более крупные размеры блоков. 32-битные блоки могут легко обрабатывать 805 миллионов блоков.

Страница похожа на блок, но эквивалентна оперативной памяти. Блоки обычно представляют собой наименьшую единицу «холодного» хранилища, а страницы — наименьшую единицу хранения в оперативной памяти. Я могу ошибаться, но мне кажется, что типичный размер страницы также равен 4 КБ памяти.

Использование страниц зависит от того, как SAN хранит данные на серверной части. При работе с SAN, использующей виртуализацию (Compellent), подкачка — это то, как SAN перемещает данные между типами дисков. (от 15 000 об/мин до 7 000 об/мин)

Пейджинг — это метод операционной системы SAN для оптимизации и отслеживания хранимых данных. Поэтому, когда вы записываете данные в свой массив, запись обычно разбивается на управляемые сегменты. Мой текущий массив может отслеживать страницы размером 512 КБ, 2 МБ и 4 МБ. Эти сегменты занимают место в памяти, и чем меньше используемая страница, тем больше памяти вы обычно потребляете.

Другое Обратите внимание, что большинство массивов представляют собственные сектора размером 4 КБ для серверов (в форме LUN), независимо от дисков, стоящих за массивом. Это связано с тем, что некоторые приложения, такие как SQL Server, были созданы и оптимизированы для собственных секторов размером 4 КБ.

Фрагмент

На самом деле у чанка нет строгого определения, обычно он более специфичен для использования. Например, «кусок» данных может быть объемом данных, которые приложение обрабатывает с диска за раз. Например, файл журнала имеет размер 100 МБ, и приложение для синтаксического анализа считывает файл и обрабатывает его фрагментами по 5 МБ. Чтение 5 МБ -> Обработка 5 МБ -> Чтение 5 МБ -> Обработка 5 МБ и т. д. В некоторых системах хранения это может быть уровень абстракции над блоком, например, когда речь идет о кэшировании чтения/записи, он может записывать данные на диск фрагментами. которые не совпадают по размеру с одним блоком. Многократное чтение и запись фрагментами может повысить производительность.

Читайте также: