Я недавно читал о дисках, что привело меня к трем различным сомнениям. И я не могу связать их вместе. Меня путают три разных термина: block size, IO и Performance.
Я читал про суперблок на слэшрут когда я столкнулся с заявлением
Будет выполнено меньше операций ввода-вывода в секунду, если размер блока вашей файловой системы больше.
Из этого я понимаю, что если я хочу прочитать 1024 КБ данных, диск (скажем, A) с размером блока 4KB / 4096B потребует больше операций ввода-вывода, чем диск (скажем B) с размером блока 64 КБ.
Теперь мой вопрос: сколько еще операций ввода-вывода потребуется для диска A?
Насколько я понимаю, количество запросов ввода-вывода, необходимых для чтения этих данных, также будет зависеть от размера каждого запроса ввода-вывода.
So who is deciding what is the size of the IO request? Is it equal to the block size? Некоторые люди говорят, что ваше приложение определяет размер запроса ввода-вывода, что кажется достаточно справедливым, но как тогда ОС разделяет один запрос на несколько операций ввода-вывода. There must be a limit after which the request splits in more then one IO. How to find that limit ?Is it possible that in both disk (A and B) the data can be read in same number of IO?Does reading each block means a single IO ? If not how many blocks can be maximum read in a single IO?If the data is sequential or random spread, does CPU provides all block address to read once?Также
возможное количество операций ввода-вывода в секунду = 1 / (средняя задержка вращения + среднее время поиска)
Пропускная способность = IOPS * размер IO
Сверху IOPS для диска всегда будет фиксированным, но размер IO может быть переменным. Таким образом, для расчета максимально возможной пропускной способности нам потребуется максимальный размер ввода-вывода. И из этого я понимаю, что если я хочу увеличить пропускную способность с диска, я буду делать запрос с максимальным количеством данных, которые я могу отправить в запросе. Верно ли это предположение?
Прошу прощения за слишком много вопросов, но я читал об этом некоторое время и не смог получить удовлетворительных ответов. Я нашел разные взгляды на одно и то же.
я думаю Статья в Википедии объясняет это достаточно хорошо:
Отсутствие одновременной спецификации времени отклика и загруженности, IOPS по сути бессмысленны.
...
Как и результаты тестов, показатели IOPS, публикуемые производителями устройств хранения, не имеют прямого отношения к производительности реальных приложений. ...
Теперь к вашим вопросам:
Итак, кто решает, каков размер запроса ввода-вывода?
Это и легкий, и сложный вопрос для такого непрограммиста, как я.
Как обычно, ответ неудовлетворительный "это зависит"...
Операции ввода-вывода в отношении дискового хранилища приложением обычно являются системными вызовами операционной системы, и их размер зависит от того, какой системный вызов сделан ...
Я лучше знаком с Linux, чем с другими операционными системами, поэтому буду использовать его как справочник.
Размер операций ввода-вывода, таких как open() , stat() , chmod() и подобных почти ничтожно мало.
На вращающемся диске производительность этих вызовов в основном зависит от того, сколько приводу диска необходимо для перемещения рычага и считывающей головки в правильное положение на диске.
С другой стороны, размер read() и write() звонки изначально устанавливаются приложением и могут варьироваться от 0 и 0x7ffff000 (2 147 479 552) байта в одном запросе ввода-вывода ...
Конечно, как только такой системный вызов был сделан приложением и получен ОС, вызов получит запланировано и поставлено в очередь (в зависимости от того, использовался ли флаг O_DIRECT для обхода кэша страниц и буферов, и был выбран прямой ввод-вывод).
Абстрактный системный вызов должен быть отображен в / из операций в базовой файловой системе, которая упорядочена в дискретных блоки (размер которого обычно устанавливается при создании файловой системы), и в конечном итоге драйвер диска работает либо с секторы жесткого диска 512 или 4096 байт или страниц памяти SSD размером 2 КБ, 4 КБ, 8 КБ или 16 КБ.
(Для тестов обычно для вызовов чтения и записи обычно установлено значение 512B или 4KB, что очень хорошо согласуется с базовым диском, что обеспечивает оптимальную производительность.)
Должен быть предел, после которого запрос разбивается на несколько операций ввода-вывода. Как найти этот предел?
Да, есть предел, в Linux, как указано в руководстве, один read() или write() системный вызов вернет максимум 0x7ffff000 (2 147 479 552) байта. Чтобы читать файлы большего размера, вам потребуются дополнительные системные вызовы.
Означает ли чтение каждого блока один ввод-вывод?
Насколько я понимаю, обычно каждое появление системного вызова считается событием ввода-вывода.
Один read() Системный вызов считается как 1 событие ввода / вывода и ни X, ни Y операций ввода-вывода, независимо от того, как этот системный вызов транслируется / реализуется для доступа к блокам X из файловой системы или чтения секторов Y с вращающегося жесткого диска.
Похоже, вы пытаетесь расшифровать это утверждение:
«Меньше операций ввода-вывода в секунду будет выполняться, если размер блока вашей файловой системы больше».
Позвольте мне попытаться перефразировать это утверждение, чтобы сделать смысл оригинального автора более ясным:
"Чтобы прочитать данный файл с определенным размером (скажем, 10 МБ), файловая система, отформатированная с большим размером блока, будет наверное необходимо выполнять меньшее количество операций чтения, чем файловая система, отформатированная с меньшим размером блока ".
Надеюсь, моя перефразировка имеет больше смысла, чем оригинал.
Чтобы правильно проанализировать это утверждение и понять причину а) использования термина «файловая система» вместо диска и б) этого надоедливого «вероятно», вам нужно узнать намного больше обо всех уровнях программного обеспечения между данными, расположенными на диске (или SSD) и пользовательские приложения. Я могу дать вам несколько советов, чтобы начать поиск в Google:
Для вращающихся дисков:
Узнайте о кешировании:
Страничный / буферный кеш в ядре ОС
Кэширование ввода-вывода в библиотеках пользовательского уровня (наиболее важными из которых являются libc и libc ++)
Для SSD или другого флеш-хранилища есть некоторые дополнительные сложности. Вам следует узнать, как работает флэш-хранилище в единицах страниц и почему для любого флэш-хранилища требуется процесс сборки мусора.