Как при старте и в процессе работы поддерживать информацию о скорости диска?

Прокалибровать системную информацию о дисковой подсистеме какой-то константой, а потом - смотреть по факту и менять оценку? Пишется же файл наверняка порциями, можно в процессе понять текущую скорость.

Похоже на поиск моментальной средней температуры по больнице.

А что за скорость диска? Скорость вращения постоянна. Число Direct и Cached IO по идее можно брать из ОС.

Как-то так?

blktrace

А если мерить записано сколько и за сколько времени, поддерживать в среднем только его, не вариант?

Попробую предложить решение в общем виде. Интересно предсказать скорость записи на диск. Для любого предсказания нужна тренированная модель. Пусть линейная в виде одного коэффициента в виде средней скорости записи. Вероятно модель придётся обучать с учётом текущего прогресса. Дальше стоит учесть конкуррентность записи и в частности конкурренцию от неучтённых факторов. Вдруг на тот же диск еще кто-то бекапы льёт. Теперь можно прикинуть, что у модели может быть на входе. Текущая скорость записи, iowait, util, длинну очереди на контроллере, предыдущее состояние модели, Объем данных для записи. Что с флашем? Вероятно важным будет объём свободной памяти. Системные параметры можно снять vmstat iostat. Ну и собрать из этого какую-то предсказалку упростив задачу до пары самых важных в конкретном случае параметров. Можно сделать несколько простых моделей от одного параметра. В полной неизвестности я бы взял среднюю скорость предыдущей записи и util для диска. Util предположил бы линейным или табличным. И калибровал (обучал) бы его по предыдущим экспериментам. . Я люблю взвешенные средние. Взять и усреднить предсказания моделей по весам. И там уже смотреть какая моделька лучше сработает

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

Чтобы постоянно поддерживать информацию о скорости записи можно имитировать эту самую запись, если диск не жалко конечно. Т.е. пишем постоянно, но или какую-то туфту или реальные данные.

А кто-то ещё на диск пишет или твой процесс единственный писатель?

Вообще, если подумать, то нужные данные есть где-то в потрохах ОС и файлухи. Можно попытаться их от туда достать.

Собственно а какая цель? Зачем нужна инфа о скорости диска? Для шедулинга? Для предсказания времени операции? Еще для чего-то?

Я не понял, вот честно"Правдивый прогресс-бар" так и надо рисовать, правдиво. Записал 10% - отобразил 10%

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

дельта производных по времени, минус локальные экстремумы. типа отсечки по квадратичному отклонению.

Записать тестовый файл и замерить скорость.

Скажу, скорее всего, очевидную мысль:1. Писать чанками фиксированной длины2. Первые несколько чанков с O_DIRECT или fsync3. Для фиксации прогресса по первым чанкам скорость считать == 75МБайт/сек (консумерский ноутбучный шпиндель)4. Пересчёт исходя из полученных цифр, беря в расчёт наихудший вариант -5%.

Очень интересная задача. Про константу предложили. Можно ее вынести в конфиг, написать значения для разных типов: hdd, ssd, nvme и т.д. А потом калибровать. Или начинать консервативно, с небольшого размера очереди и понемногу увеличивать. Но параметр имхо лучше, потому что люди которые используют базы данных не дураки, смогут подкрутить под железо.

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

наделать сэмплов открытых данных о состоянии системы (параметры диска, процессы etc) + фактической скорости записи и натренировать на этом xgboost например <img height="16" width="16" alt="😃" referrerpolicy="origin-when-cross-origin" src="https://static.xx.fbcdn.net/images/emoji.php/v9/t51/1/16/1f603.png">

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