S>и логи при креше часто не успевают записаться на диск

Делаешь mmap'ed файл и пишешь в эту память как в циклический буфер. При нормальном выходе из приложения пишешь туда метку, что файл закрыт корректно (или обнуляешь его, например). При старте приложения проверяешь эту метку. Если ядро ОС будет работоспособно при падении приложения — данные будут записаны в файл после остановки приложения. Если же у тебя произошел креш по причине падения питания, например, то и логи тебе эти не нужны.Накладные расходы на такой журнал — каждые 30 секунд (по умолчанию) в Linux происходит сброс "грязных" страниц в файлы. Еще, как я понимаю, после сброса этих данных на диск

S>и логи при креше часто не успевают записаться на диск

Делаешь mmap'ed файл и пишешь в эту память как в циклический буфер. При нормальном выходе из приложения пишешь туда метку, что файл закрыт корректно (или обнуляешь его, например). При старте приложения проверяешь эту метку. Если ядро ОС будет работоспособно при падении приложения — данные будут записаны в файл после остановки приложения. Если же у тебя произошел креш по причине падения питания, например, то и логи тебе эти не нужны.

Накладные расходы на такой журнал — каждые 30 секунд (по умолчанию) в Linux происходит сброс "грязных" страниц в файлы. Еще, как я понимаю, после сброса этих данных на диск страницы памяти будут помечены "чистыми" и при первой записи будет PAGE FAULT с переключением в контекст ядра, чтобы пометить страницу как "грязную". Итого: скорость такого журналирования равна скорости записи в память + асинхронный сброс данных на диск раз в 30 секунд + переключение в контекст ядра для пометки каждой страницы как "грязной" (т.е. страницы нужно mmap'ить по 2M). Можно журнал сбрасывать на диск принудительно, если нужно быстрее, но опять же это будет делаться асинхронно, т.е. приложение не будет ждать.

Короче, либо используй нормальный логгер, либо напиши сам (ну, или дай студенту третьекуру такую задачу — должен справиться).