вопросы по поводу работы с жесткими дисками в linux

#linux #многопоточность #hardware

Здравствуйте, читаю "Системное программирование" Роберта Лава, он пишет про fsync(),
O_SYNC, но не понятно о назначении этих функций...


Где необходимы вызовы этих функций? Если б это было нужно всегда, то синхронизация
бы была по дефолту установлена. 
Цитата из книжки.


  Налицо огромное увеличение издержек, поэтому синхронизированный ввод-вывод следует
использовать только при отсутствии альтернатив.

Со сколькими параллельными операциями ввода / вывода может работать жесткий диск?
Ну т.е. хочу я в 1000 нитях параллельно читать или писать в разные файлы на диске,
будет ли толк, или начнет всё тормозить (имеется ввиду не из-за переключения контекста,
а из-за каких-то причин с самим диском)?

    

Ответы

Ответ 1

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

Впрочем, начну лучше со второго вопроса:


  со сколькими параллельными операциями ввода/вывода может работать жесткий диск?


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

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


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


Простым математическим подсчётом получаем механический предел в 120 операций в секунду
для 7200 rpm дисков (с частотой вращения 7200 оборотов в минуту). Будет меньше операций
если надо читать с разных областей диска, т.к. перемещение магнитной головки штука
медленная мало того из-за того что механическая операция но должна осуществляться точно
(речь о микрометрах), так ещё и в условиях вибрации от собственно самого диска и всех
прочих вибраций. Как итог вполне можно попасть не на ту дорожку и придётся перепозиционировать
головки ещё раз.

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

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

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



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

Но, к счастью, за последние лет 10 сильно подешевела flash-память и появились SSD
диски. Дисками их называют только по привычке, на самом деле никакой механики там уже
нет. И параллельная обработка запросов (пусть и за счёт обращений к разным кристаллам
памяти) и куда более внушительная производительность по метрике количества операций
в секунду (iops) - всё возможно. И, вероятно, со временем будут пересмотрены в сторону
упрощения и планировщики ввода-вывода (собственно blk_mq в ядре linux уже) и упрощены
другие нагромождения этих десятилетий когда для хранения данных использовалась медлительная
механика. У flash-памяти своих интересных фокусов тоже хватает (например, есть не 2
операции чтение и запись, а чтение, стирание, запись - запись возможна только в предварительно
очищенную страницу. Отсюда выросла необходимость в команде trim) - но это уже тема
отдельных изысканий.


Ответ 2

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