Hi Ruben, The risk of #2 is that if anybody accidentally does anything with the file, you might be screwed. It's also true you insert data in RRD shortly after the file is created so the probability is slim. But in this sense you can perhaps consider relying on file ctime rather than mtime.
Relying on the file name is IHMO the way to go. Depending on how you are inserting data in a RRD file, your option #1 looks OK to me (granted that you define somewhere the config in use and parse it accordingly - or more simply you define the step explicitely). Cheers, Paolo On Thu, Mar 29, 2012 at 12:42:05PM +0200, Ruben Laban wrote: > > Hi Paolo, > > Thanks for the clarification. > > Now to think of a nice way to deal with this "issue". > > * Manually add the interval to the file's timestamp, or > * Rely on the file's mtime, or > * Ignore the problem and insert "inaccurate" data into the RRDs > > None of those are really idea, tho I guess the 2nd one will turn out to > the most reliable. > > Regards, > Ruben Laban > > On 29/Mar/2012 09:01, Paolo Lucente wrote: >> Hi Ruben, >> >> That is intended. What is encoded in the filename is the basetime of a >> timeslot, what in a SQL table would be the stamp_inserted field. The OS >> timestamp of the file, ie. when the file was last touched, encodes what >> in a SQL table would be the stamp_updated field instead. >> >> Cheers, >> Paolo >> >> On Wed, Mar 28, 2012 at 11:14:48AM +0200, Ruben Laban wrote: >>> Hi Paolo, list, >>> >>> Just now I noticed another unexpected behavior: >>> >>> -rw------- 1 root root 402 2012-03-28 10:50 >>> pmacct_up0_in_total_20120328-1045 >>> -rw------- 1 root root 402 2012-03-28 10:55 >>> pmacct_up0_in_total_20120328-1050 >>> -rw------- 1 root root 402 2012-03-28 11:00 >>> pmacct_up0_in_total_20120328-1055 >>> >>> The documentation states: >>> >>> KEY: [ sql_table | print_output_file ] >>> DESC: ... Dynamic names are supported through the use of >>> variables, which are computed at the moment when data is purged to the >>> backend. ... >>> >>> So I'd expect the file written at 10:50 to called -1050, not -1045. >>> >>> Am I interpreting the documentation wrong, did I stumble upon a bug, or >>> something completely different? >>> >>> Regards, >>> Ruben Laban >>> >>> _______________________________________________ >>> pmacct-discussion mailing list >>> http://www.pmacct.net/#mailinglists >> >> _______________________________________________ >> pmacct-discussion mailing list >> http://www.pmacct.net/#mailinglists > _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
