[rrd-developers] Possible race conditions / data loss in rrdcached?

[Sebastian Harl]

Hi Kevin,

On Sun, Jul 12, 2009 at 10:23:19AM -0500, kevin brintnall wrote:
> On Sun, Jul 12, 2009 at 12:15:54PM +0200, Sebastian Harl wrote:
> > I've just stumbled across the following (possible) issue. Unfortunately,
> > I don't have the time to have a more in-depth look at it, but maybe
> > Kevin and / or Florian can comment on that:
> 
> Sebastian, your summary is correct.

Thanks for confirming that.

> This unlock allows rrdcached to continue processing other updates as soon
> as possible.  stat() may block on a system that is heavily IO constrained
> (sometimes for multiple seconds).

Hrm, frankly, imho, this does not justify a bug like this.

> If the cache lock were held during that time, we'd introduce the exact
> type of IO-bound update delay that rrdcached is aiming to avoid.
[...]
> For rrdcached to be beneficial, the arrival rate of new nodes must be
> _significantly_ smaller than the arrival rate of updates.  Therefore, I
> think this is a sensible decision.

Imho, it's rather the contrary: Since new nodes are added only very
rarely, the overhead of adding new nodes is rather irrelevant and, thus,
it's not sensible to _not_ fix that bug.

Anyway, this should be easy to fix. See the patch, I'll send in a
minute. Beware, though, that I do not have a RRDCacheD setup, so the
patch is mostly untested - it compiles though ;-)

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090713/3a62103d/attachment.bin