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

Здравствуйте, читаю "Системное программирование" Роберта Лава, он пишет про fsync(), O_SYNC, но не понятно о назначении этих функций...
Где необходимы вызовы этих функций? Если б это было нужно всегда, то синхронизация бы была по дефолту установлена. Цитата из книжки.
Налицо огромное увеличение издержек, поэтому синхронизированный ввод-вывод следует использовать только при отсутствии альтернатив. Со сколькими параллельными операциями ввода / вывода может работать жесткий диск? Ну т.е. хочу я в 1000 нитях параллельно читать или писать в разные файлы на диске, будет ли толк, или начнет всё тормозить (имеется ввиду не из-за переключения контекста, а из-за каких-то причин с самим диском)?

Ответ

fsync и его подвиды требуются, когда приложение хочет получить гарантию, что данные уже записаны на физический диск, а не будут записаны на диск.
Впрочем, начну лучше со второго вопроса:
со сколькими параллельными операциями ввода/вывода может работать жесткий диск?
С одной. Потому что внутри HDD только один блок головок чтения-записи. И из-за ограничений физических законов нашей вселенной этот блок может одновременно находиться только над одним местом магнитного диска.
И следующее механическое ограничение - магнитные диски вращаются с постоянной скоростью, а читать-писать можно только в одном месте. Значит если мы хотим прочитать сектора в разных местах диска нам требуется:
спозиционировать на эту дорожку блок головок чтения-записи дождаться, пока требуемый сектор не окажется под головкой
Простым математическим подсчётом получаем механический предел в 120 операций в секунду для 7200 rpm дисков (с частотой вращения 7200 оборотов в минуту). Будет меньше операций если надо читать с разных областей диска, т.к. перемещение магнитной головки штука медленная мало того из-за того что механическая операция но должна осуществляться точно (речь о микрометрах), так ещё и в условиях вибрации от собственно самого диска и всех прочих вибраций. Как итог вполне можно попасть не на ту дорожку и придётся перепозиционировать головки ещё раз.
Но зато можно успеть прочитать больше данных, если они идут последовательно в секторах одной дорожки.
В общем, механический диск - штука крайне медлительная и прогресс CPU и оперативной памяти (не имеющих механический частей и потому значительно более быстрых) в прошлом тысячелетии потребовали вводить всевозможные ухищрения. В частности, операционные системы начали кешировать операции чтения и записи данных в неиспользуемых в данный момент выполняющимися программами областях оперативной памяти. И если с чтением всё просто - точно такая же копия лежит в энергонезависимой памяти механических дисков - то с кешированием записи как-то печальнее. Операционная система отвечает приложению "данные записаны", а на самом деле они размещены в оперативной памяти и будут записаны когда-нибудь чуть позже, может через несколько секунд. И это замечательно работает и ускоряет все операции с дисков. Вот только при критическом сбое системы (например по питанию) данные будут потеряны.
И чтобы дать приложениям возможность попросить систему именно записать какие-то данные в энергонезависимую память и добавили вызов fsync, который синхронизирует кэш записи с дисками.

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