On Thu, Dec 11, 2014 at 02:03:37PM +0100, Michal Privoznik wrote: > On 11.12.2014 03:27, Chun Yan Liu wrote: > > > > > >>>>On 12/5/2014 at 09:54 PM, in message <5481B907.4040507@xxxxxxxxxx>, Cole > >Robinson <crobinso@xxxxxxxxxx> wrote: > >>On 12/05/2014 03:40 AM, Chunyan Liu wrote: > >>> <snip/> > >>>+ # Refresh pools before poll_helper. For those > >>>+ # 'active' but target path not exist (or other reasons > >>>+ # causing the pool not working), but libvirtd not > >>>+ # refresh the status, this will make it refreshed > >>>+ # and mark that pool as 'inactive'. > >>>+ objs = backend.listAllStoragePools() > >>>+ for obj in objs: > >>>+ try: > >>>+ obj.refresh(0) > >>>+ except Exception, e: > >>>+ pass > >>>+ > >>> return _new_poll_helper(origmap, name, > >>> backend.listAllStoragePools, build_func) > >>> else: > >>> > >> > >>This is a very heavy hammer, refresh is a potentially long running operation > >> > >>so this could cause decent slowdown in some scenarios. > >> > >>IMO this is essentially a libvirt bug, for pools with target directories > >>(dir, > >>fs, netfs), libvirt should be periodically checking the directory ctime and > >>doing the pool refresh for us. And if the target has disappeared, it shuts > >>down the pool (like shutting down a VM if it crashes). > > > Makes sense to me. Although, refreshing a dir can again be a long running > job (consider dir pool built in a NFS mount). I wonder if we should use > {d,i,fa}notify or if checking ctime is enough. I think ultimately libvirt should make use of *notify in many places in its code, including the filesystem based storage pools. ie if we can do any automatic refresh so we're guaranteed always up2date we should. Not all storage pools will support that, so we'd probably want to expose some kind of capability info about storage pool backends to describe their features to apps. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list