On 27/05/2015 11:07, Kevin Wolf wrote: > This is the first part of what's troubling me with this series, as it > makes me doubtful if op blockers are the right tool to implement what > the commit message says (block device I/O). This is "are we doing the > thing right?" > > The second part should actually come first, though: "Are we doing the > right thing?" I'm also doubtful whether blocking device I/O is even what > we should do. > > Why is device I/O special compared to block job I/O or NBD server I/O?
Because block job I/O doesn't modify the source disk. For the target disk, block jobs should definitely treat themselves as device I/O and register notifiers that pause themselves on bdrv_drain. > If the answer is "because block jobs are already paused while draining" > (and probably nobody thought much about the NBD server), then chances > are that it's not the right thing. In fact, using two different > mechanisms for pausing block jobs and pausing device I/O seems > inconsistent and wrong. > > I suspect that the real solution needs to be in the block layer, though > I'm not quite sure yet what it would be like. Perhaps a function pair > like blk_stop/resume_io() that is used by bdrv_drain() callers and works > on the BlockBackend level. This is suspiciously similar to the first idea that I and Stefan had, which was a blk_pause/blk_resume API, implemented through a notifier list. Paolo
