File descriptors are left open by the filesystem store

[Flavio Percoco]

From this m-l thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/065889.html

I believe what's happening is that the ChunkedFile code opens the file and
creates the iterator. Nova then starts iterating through the file.

If nova (or any other user of glance) iterates all the way through the file
then the ChunkedFile code will hit the "finally" clause in __iter__() and
close the file descriptor.

If nova starts iterating through the file and then stops (due to running out
of room, for example), the ChunkedFile.__iter__() routine is left with an open
file descriptor. At this point deleting the image will not actually free up
any space.

I'm not a glance guy so I could be wrong about the code. The
externally-visible data are:
1) glance-api is holding an open file descriptor to a deleted image file
2) If I kill glance-api the disk space is freed up.
3) If I modify nova to always finish iterating through the file the problem
doesn't occur in the first place.

Chris

[Stuart McLaren (stuart-mclaren)]

I wonder if:

https://review.openstack.org/#/c/119132

would help here? ie if the client connection from nova stops pulling data it will eventually get torn down by the glance server -- hopefully releasing any fds the server has open for servicing that request.

Similarly, from the client side:
https://review.openstack.org/#/c/168673

Both of these are time-out rather than (better) state driven.

[Ian Cordasco (icordasc)]

Flavio, do you intend to address this still?