Использование перехватов операций для бэкапа файлов в macOS “на лету”

[vit9696]

Добрый день,

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

• Почему нельзя было воспользоваться fsevents? Они из userspace доступны и предназначены в общем-то как раз для вашего случая. Проблемы асинхронности с ними вполне должны решаться через flock.
• Синхронный запрос в userspace на каждую I/O операцию будет приводить к жутким лагам, если не делать это сильно избирательно для пары файлов, но тогда лаги всё равно будут, пусть и при использовании этих файлов.
• Непонятно, как за такой варварский патчинг ядра вам дали сертификат для подписи драйвера, и пока ещё его не отобрали.

[V1tol]

Apple для Catalina сделала мониторинг ФС ещё проще. Такое приложение можно будет даже через AppStore распространять.

[aglab2]

Здравствуйте!

• Как я понимаю, flock является лишь advisory, то есть нельзя гарантировать, что любое приложение поведет себя корректно и попросит flock перед записью.
• Синхронный запрос можно заменить асинхронным, который будет производить чтение части, которая еще не была сохранена. Я рассматриваю этот подход как улучшение текущего, но уже сейчас я проверяю нужно ли делать copy-on-write — в сервисе. Также пока живу с замедлениями текущего подхода.
• На macOS 10.16 скорее всего начнут отрезать поддержку загрузки 3rd party кекстов, поэтому все равно придется переходить на DriverKit API. Мой способ в любом случае скоро станет deprecated, поэтому делюсь хитростями пока еще есть шанс поэкспериментировать. Да и подход не такой уж варварский, в read-only секции и чужие кексты не пишем

[kITerE]

Впрочем, вероятность изменения паттерна функции на порядок меньше, чем вероятность изменения порядка полей. Так что мы решили остановиться на втором методе.

1. На чем основывался расчет вероятности? Есть какая-то статистика по изменениям паттернов кода и перетасовке полей?
2. Почему не использовать каскад методов: если не получилось найти паттерн в коде функции, тот искать по смещениям?

[aglab2]

1. Вероятность основывается на результатах blame коммитов в ядро XNU GitHub blame для VNOP_CREATE и GitHub blame для struct vnode. Видно, что структура vnode менялась последний раз 3 года назад против 6 лет для VNOP_CREATE.
2. Все верно, именно каскад и должен использоваться. Также необходимо валидировать саму таблицу, производя чтение ее содержимого — хотя бы проверить, что в таблице находятся указатели на функции.