[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] That xenstored console leak...
On Mon, Jan 14, 2008 at 10:55:37PM +0000, John Levon wrote: > On Mon, Jan 14, 2008 at 09:54:50PM +0000, Keir Fraser wrote: > > > >> Yes, device controllers clean up by deleting /vm/<uuid>/path/to/device. > > >> This > > >> aliases with the new domain's device information (because they're really > > >> the > > >> same vm) and so when the old domain is cleaned up the new domain loses > > >> information. Disambiguating with an extra level of indirection seemed the > > >> simplest fix for this. I'm not sure why this leads to xenstore leaks. > > >> > > >> When a domain is finally garbage collected in xend, perhaps we should > > >> delete > > >> its entire /vm/<uuid>/<unique-number>? That would seem a nice and > > >> reasonable > > >> catch-all. > > > > > > The lack of the latter explains the former - because each instance has a > > > unique /vm path, there's nothing that ever cleans up the older path > > > contents (image etc.). Right? > > > > I don't understand what you mean. There's no code to delete the entire /vm > > path, regardless of whether the path is /vm/<uuid>/ or /vm/<uuid>-<number> > > (I'm pretty sure). > > The old code re-used the same /vm/<uuid>/ path, so there was no leak. > The new code creates a completely new /vm/<uuid>-<number> path, leaking the > old one (/vm/<uuid>-<oldnumber>). Yes, I noticed that too - its rather peculiar - the idea of the /vm/ hierarchy was that it was persistent for any individual VM, across creation attempts. If we append <number> on the path each time it ceases to be persistent and we might as well just kill off /vm and use /local/<domid> for everything. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |