So, one busy process performs a file operation that triggers a system restore checkpoint, and the OS locks the entire drive during this file operation? Sounds strange to me.

Is the problem that the checkpointing critical section has the same duration as the triggering file operation?

I get that there must be some sort of critical section for setting a checkpoint, but I don't understand why it takes so long, and why it would be affected by how busy the userspace process that triggered it is.

I would expect it to have a short barrier-style critical section; drain all outstanding writes, record some checksum or counter from a kernel data structure, and then release all writers again.

In my mind this should be kernel code only, entirely unaffected by userspace, and if designed nicely, quite fast.

So I guess I don't get what is going on here.