Собственно все необходимые вопросы, на которые нужно обратить внимание, вы указали в вопросе, гуглить по каждому но в большинстве своем все ответы можно сформулировать самостоятельно, просто подумав и включив логику.
1. Случайный и многопоточный доступ - принципиальная необходимость задумываться об этом исходит из физической особенности накопителей, последовательный доступ от случайного (имеется в виду как у hdd так и у ssd (в меньшей степени, зависит от размера читаемого блока кластера, потребительскиее ssd это 256кб) значительно отличаются (на порядок или даже два) по времени. Аппаратные контроллеры на материнской плате и даже на диске (или драйвера и планировщик ос) могут физически считывать данных больше чем потребуется (read ahead), делая это фоном, после запроса и сохраняя в своей памяти.
Если несколько приложений одновременно потребуют данные с разных областей устройства хранения, специальный планировщик ос может приостанавливать работу этих приложений, собирая как можно больше запросов на данные, сортируя их для оптимальной их обработки. Пользовательское приложение может делать это значительно эффективнее, если заранее озаботится о том, как именно данные будут храниться на диске (обычно речь идет о хранении данных минуя файловую систему).
2. Кеширование чтения - в подавляющем большинстве случаев хватает функционала операционной системы, операционные системы используют разные стратегии (fifo или к примеру на основе частоты запросов), системные вызовы ОС позволяют управлять стратегией кеширования, в т.ч. полное ее отключение (это может быть недоступно для некоторых файловых систем, например fuse в linux, если об этом не позаботился их разработчик), с целью перенести логику выбора кеширования данных в приложение.
3. Кеширование (буферизирование) записи - приложение может управлять, стоит ли ждать окончания физической записи данных на диск или это можно сделать фоном или даже отложить на потом. Например fflush позволяет принудительно сбросить буфера при использовании fwrite (и других от stdlib), более низкоуровневые вызовы позволяют точнее управлять процессом. Помимо инструментов управления кешированием на уровне приложения есть способы настроить это на уровне ОС (например ext4 позволяет настроить стратегию записи data=writeback, это делает файловую систему уязвимой к сбоям но значительно ускоряет запись, так как даже fflush из приложения не будет ждать окончательной записи), так же разные сетевые файловые системы могут накладывать дополнительные ограничения (точно помню что nfs обрабатывает fwrite по другому в отличии от локальных записей, делая больше лишних действий на диске)
p.s. про mmap, меанизмы ОС (как linux так и windows) позволяет вместо работы с файлом по кусочкам (fopen/fread/fwrite/...) 'замапить' указанный файл или даже раздел/диск на область памяти, при доступе к которой прозрачно будут совершаться чтения и записи на диск. Этот способ работы с файлами зачастую самый производительный (кстати по умолчанию используются на исполняемый файл приложения и .dll/.so) и очень часто еще и удобнее, так как кеширование данных будет произведено средствами ос, и при повторном запуске приложения данные уже будут в памяти (при обычном fopen их пришлось бы считывать в память, т.е. копировать что дает 2x накладные расходы на процессор).
-------------
4. Файловые системы это уровень абстракций ОС, значительно добавляет накладные расходы на работу с данными но за счет удобства (например возможность расширить хранилище без полного копирования данных, просто увеличив размер раздела или добавив новый накопитель, как это позволяют файловые системы - комбаины типа btrfs/zfs), разные файловые системы организуют хранение по разному, что значительно влияет на скорость как записи так и чтения.
Например cow файловые системы (xfs/zfs/btrfs) каждое последующую запись делают последовательно, даже если записываемые чанки/кластеры принадлежат разным файлам, даже если это модификация а не добавление в конец, что благосклонно сказывается на скорость записи но отвратительно фрагментирует размещение файлов на диске (там есть механизмы борьбы с этим), т.е. для хранилище файлов разного размера, считываемых/изменяемых целиком такие файловые системы идеальны, но для баз данных наоборот очень неэффективны (в таких фс можно принудительно отключить cow для определенных файлов). btrfs/zfs за эти накладные расходы (незначительные) дают бонусом функционал быстрых снапшотов (почитай про btrfs snapshot incremental backup) и высокую устойчивость к сбоям.
Еще пример, файловые системы, с целью защитить данные от сбоев, добавили к функционалу понятие журнал, промежуточное место, куда записываются данные (метаданные) до тех пор пока приложение не зафиксирует изменения (закрытие файла или fflush), в нормальных ОС существует возможность разместить этот журнал на отдельном, более быстром, накопителе (например ext3/ext4) или отключить полностью. Это позволяет заметно ускорить запись и не покупать на весь объем данных быстрый и дорогой накопитель.
Было время, когда можно было буквально (кажется у xfs но я могу ошибаться) указать разные накопители для метаданных (информация о том как файл размещен на диске и информация о атрибутах файлов) и самих данных, что тоже в условиях значительного отличия скорости работы емких hdd и быстрых но не емких ssd, сэкономить на построении хранилища.
5. Сжатие данных на лету - некоторые файловые системы позволяют прозрачно для приложений пропускать данные через библиотеку сжатия (в пределах кластера или даже нескольких соседних), например ntfs использует compress, а btrfs позволяет выбирать, например zstd (один из лучших по соотношений скорость/сжатие), было время когда включение сжатия на медленных накопителях давала двух-трех кратное ускорение скорости чтения практически бесплатно (а запись почти не замедлялась но повышалась нагрузка на процессор), на современных же накопителях процессор может не поспевать (но есть дорогие контроллеры с таким функционалом).
Еще есть тип сжатия - sparse files (дырявые файлы), части файла, в которые не производилась запись, физически не занимают место (фактически тратится место только крохотная часть в области метаданных файловой системы), при чтении таких частей будут возвращены нули, так же есть функции по замене ранее записанных частей файла на такие дырки. Такие файлы могут понадобиться, например, когда нужно хранить огромные разряженные матрицы с индексацией по позиции, индекс тут будет использоваться от файловой системы но выигрыш по производительности сомнителен и требует измерений под ваши данные.
p.s. любая сторонняя библиотека, добавляющая еще один уровень абстракции к хранилищу, может дать выигрыш только если стратегия работы с данными совпадает с той, на что заточена эта библиотека. Например реляционные базы данных дают готовый и обширный функционал по индексированию данных, многопользовательских транзакций но за счет больших накладных расходов на их поддержание. Помню был тут вопрос про хранение терабайтов данных числовой ключ -> крохотное значение (несколько байтов хеш), так вот майкрософтовская sql уже с миллионами записей могла до секунды на запись диском шерстить (тысячи iops), когда как самодельный и примитивный велосипед с одноуровневым индексом по хешу от значения мог дать скорость доступа и записи 1к1 iops накопителя (от 1 вызов к диску на запрос чтения и от 2 - на запись).