| I'm not following what you're saying. Why do we need a callback? In this imaginary design, the syscalls you make would look something like: - BeginChannelTx -> return ChannelTxID - ReadZFSProperties(ChannelTxID, params) -> return data - DestroySomeDatasets(ChannelTxID, params) -> ok - CommitChannelTx(ChannelTxID) Notably, DestroySomeDatasets doesn't actually do any work. It merely records which datasets you want to destroy. There are no callbacks as far as I can see: there's no kernel thread waiting on a user thread to do something. This way also lets you express branching. The drawback of this approach is you need a lock on all mutating administrative commands when you call BeginChannelTX. I talked to a ZFS dev, and he said that with ZFS' design, that's actually the txg sync lock. This means that while reads will proceed, writes will only proceed for a short period of time, and nothing will make it to disk. The overhead of making all these syscalls was also judged to be problematic. |