On 9 June 2015 at 07:53, Chris Friesen <chris.frie...@windriver.com> wrote: > On 06/08/2015 12:30 PM, Robert Collins wrote: >> >> On 9 June 2015 at 03:50, Chris Friesen <chris.frie...@windriver.com> >> wrote: >>> >>> On 06/07/2015 04:22 PM, Robert Collins wrote: >> >> >>> Hi, original reporter here. >>> >>> There's no LB involved. The issue was noticed in a test lab that is >>> tight >>> on disk space. When an instance failed to boot the person using the lab >>> tried to delete some images to free up space, at which point it was >>> noticed >>> that space didn't actually free up. (For at least half an hour, exact >>> time >>> unknown.) >>> >>> I'm more of a nova guy, so could you elaborate a bit on the GC? Is >>> something going to delete the ChunkedFile object after a certain amount >>> of >>> inactivity? What triggers the GC to run? >> >> >> Ok, updating my theory... I'm not super familiar with glances >> innards, so I'm going to call out my assumptions. >> >> The ChunkedFile object is in the Nova process. It reads from a local >> file, so its the issue - and it has a handle onto the image because >> glance arranged for it to read from it. > > > As I understand it, the ChunkedFile object is in the glance-api process. > (At least, it's the glance-api process that is holding the open file > descriptor.) > > >> Anyhow - to answer your question: the iterator is only referenced by >> the for loop, nothing else *can* hold a reference to it (without nasty >> introspection hacks) and so as long as the iterator has an appropriate >> try:finally:, which the filesystem ChunkedFile one does- the file will >> be closed automatically. > > > From what I understand, the iterator (in the glance-api process) normally > breaks out of the while loop once the whole file has been read and the > read() call returns an empty string. > > It's not clear to me how an error in the nova process (which causes it to > stop reading the file from glance-api) will cause glance-api to break out > of the while loop in ChunkedFile.__iter__().
AIUI the conclusion of our IRC investigation was: - with caching middleware, the fd is freed, just after ~4m. - without caching middleware, the fd is freed after ~90s. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev