On Fri, Oct 19, 2012 at 09:47:25AM +0200, Vinzenz Feenstra wrote:
> On 10/18/2012 10:11 PM, Saggi Mizrahi wrote:
> >I don't see how pyinotify is even related to storage stats.
> Well I am not sure where I would have mentioned storage statistics.
> >It doesn't work with NFS and is a bit flaky when it comes to VFSs like proc 
> >or dev.
> >Also it doesn't check liveness or latency so the events don't really give us 
> >anything useful.
> It's not like that pyinotify is the holy grail for all purposes. I
> was talking about caching the package (rpm/dpkg) changes and have
> pyinotify track this for cache invalidation. After that I wrote that
> I really would like to cache everything.

For rpm reporting it would be enough to cache the result until
/var/lib/rpm is changed, which you can stat on every getVdsCaps call.
It's not like rpms are updated very frequently.

> >
> >The data is being taken from cache. I assume there is a prepare call there 
> >that makes everything slower.
> What is 'everything'? You might have a slightly slower start up of
> VDSM however a faster response on getCaps. once everything is going
> to be cached. I am not sure where this relates to 'make everything
> slower'.
> >This will only be fixed with new style domains that don't have a built in 
> >sdUUID.
> That is a particular problem then. And I have said that I will send
> it to the list before, so we can speak about the pro/contras in the
> proposal to fix it.
vdsm-devel mailing list

Reply via email to