On Wed, 07/03 07:58, Paolo Bonzini wrote: > Il 03/07/2013 03:10, Fam Zheng ha scritto: > > > This has the important side effect of marking the exported disk as > > > "in_use" (to use the terms before the series). Right now you can serve > > > a disk and, at the same time, stream it or mirror it or create a live > > > snapshot of it. > > > > > > Do we really want to block anything for a device being served? Perhaps > > > truncation, but maybe not even that. The NBD server is meant to be as > > > unobtrusive as possible (in some sense NBD accesses are the same as > > > guest accesses). > > > > OK, it is better to work like that. But I don't quite understand why was > > there drive_get_ref() on the device (w/o the series), as there's already > > a close notifier? And it just drive_put_ref() when bs is closed? > > The close notifier runs when the user invokes a drive_del or eject > command from the monitor. The drive_get_ref/drive_put_ref delays the > bdrv_delete until after nbd.c has cleaned up all the connections.
But drive_put_ref is called by close notifier. I think it can be omitted, registering a close notifier is enough, and close the export when drive_del calls it. It doesn't make more sense w/ drive_get_ref, does it? -- Fam
