Hi Kevin, > > I have not looked at the code, but do you only reset the journal on > > flush or when there are no data left in the cache ? This might > > cause a long running copy of cached to generate rather huge an > > unwieldy journals ... > > Currently, the journal is rotated when the flush is started. This way, > any updates which are not flushed to disk are guaranteed to be in one of > the two journals. In practice, there are not many un-flushed updates in > the old journal. The forced flush is required to guarantee that any > un-written records are entirely within the two files.
:-) > > da directory tree with bits of journal that can be unlinked as their > > content has gone to disk would seem to be a more sustainable solution > > ... > > My current implementation for (2) is a set of files rrd.journal.$TIME. > The daemon manages the files in a group, rotating the entire set (cur -> > old -> unlink). At journal replay time, the files are enumerated, sorted, > and replayed in order. In this case, a forced flush is not required. It > will take longer to finish and test this implementation. that sounds much more sustainable ... if you need encuragement for the implemntation, please let me know. I will be glad to cheer you on :-) cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers