On Mon, Oct 13, 2008 at 05:41:41PM +0200, Tobias Oetiker wrote: >Hi Daniel, > >Today [EMAIL PROTECTED] wrote: > >> >> >> Hi, >> >> I've just been reviewing the file access code and starting to implement >> a mechanism for striping multiple RRDs into one big file, to further >> reduce IO load. >> >> There are various functions in rrd_open.c (e.g. rrd_read, rrd_write) >> that can be abstracted to do what is required. >> >> However, I notice that some other files (e.g. rrd_create.c) also have >> code which accesses files directly (e.g. calling open() to create a >> file). > > >> Is there some ongoing work to centralise the file access code? Would it >> be worthwhile for me to patch some of this code (e.g. rrd_create.c) to >> go through the functions in rrd_open.c, or is there some other solution >> coming? > >I think create is one of the few places where there is local code, >you can try converting it, but there will be some generalisation >issues which caused the conversion not to happen the first time >around.
There were no technical issues but create is not performance critical as opposed to e.g. update, fetch, etc. (at least in my POV) so it was not initially converted. I would consider finishing the conversion of all such spots a cleanup. It should be straight forward to update rrd_create and eventual other leftovers to the interface provided in rrc_open.c (it deliberately mimics normal read/write semantics to ease conversion). HTH, >what you might want to keep in mind is that I intend to create a >new platform independent file format. This will also have an impact >on this ... so if you are looking closely at all this code, the >fileformat work might be integrated ... > >what I have done so fahr is documented on >http://oss.oetiker.ch/rrdtool-trac/wiki/PortableRrdFormat _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
