<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:'times new roman', 'new york', times, serif;font-size:12pt;color:#000000;"><div><br></div><div>RRD Developers,</div><div><br></div><div>I have the need to pre-create rrd datapoints before they are used; such that there are already existing datafiles on the filesystem which are in a free pool and used when required.</div><div><br></div><div>The problem is that without a free pool the system is creating the datapoints on demand when newly monitored data is being inserted. &nbsp;That for the most part is okay if the new datapoint count is low thousands. &nbsp;However the issue arises when &gt;50 thousand datapoints are required quickly. &nbsp; Creating them causes noticable latency in storing all new datapoint data.</div><div><br></div><div>So the answer seems to be pre-create.</div><div>&nbsp;</div><div>The concern I have is in the past (5 years ago) I
 tested creating rrd data files with an RRA of 1 year of data and the create time set to unix epoch. &nbsp;When doing an update to that file it seemed like the entire rrd was rewritten since none of it's 'intervals' were valid for the update time of 'now'.</div><div><br></div><div>Does the latest 1.4 version do the same thing?</div><div><br></div><div>Or is it essentially a no-cost-difference in IO to update an rrd with a start time (and thus round-robin end time) with a time interval in the future of it?</div><div><br></div><div>I don't want this feature to have a negative impact on IO in nearly the same manner as creating them would be.</div><div><br></div><div>I could try and test it, but RRD developers will know for certain what the total cost is, which is what I'm most interested in.</div><div><br></div><div><br></div><div>Thanks,</div><div><br></div><div>-Ryan</div><div><br></div><div><br></div><div><br></div><div><br></div><div
 style="position:fixed"></div>


</div><br>

      </body></html>