Hi Bernhard, > Well, I was not sure about this. rrd_info does close the fd early on, so > we cannot blindly close the fd in rrd_close. If it is ok for you, we can > change rrd_close to close the fd (and adjust the callers accordingly).
yes I think it this makes sense as rrd_cloes realy imples close ... or do you see a risk in this ? > >* why do you flag the first TWO pages ? rrd files with headers > > takeing up two pages should be pretty rare ... > > Fair enough. My small test rrd's all had about 4192 bytes of headers > (IIRC), so i thought that using 2 pages should be a good starting point. > Easy enough to change, if you are confident that 1 page is enough for > the majority. hmmm well at the moment your strategy with madvise is not entirely transparent to me ... I think we need the following: a) tell the OS that we do RANDOM access to prevent readahead while accessing the header portion b) set sequential access for stuff like rrd_fetch, rrd_resize, rrd_dump c) set DONTNEED (after reading/wrting) for all blocks except the header and the 'hot' RRA blocks. > >* for figuring the pagesize you should use getpagesize is > > available. > > So i vote for using sysconf, and adding checks for > _SC_PAGESIZE, _SC_PAGE_SIZE, PAGESIZE, PAGE_SIZE > > Ok? ok convinced ... sunos3 (or whatever os changed the page size) compatibility is probably not such an issue ... > >* if mmap is not used, then it would be cool if posix fadvise was > > still called (have not checked the code, just saw that you > > removed the check from configure) > > fadvise is still called for the FD path. Wrapping the check for fadvise > in $enable_mmap just makes sure that we do not call fadvise for mmap, > but only check for it and eventually use it for the non-mmap path. ok good tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten http://it.oetiker.ch [EMAIL PROTECTED] ++41 62 213 9902 _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
