Benny Baumann wrote:
Ben, I understand what you are saying. The question I have is not whether it's always possible and meaningful to do this, the question is whether it's possible to arrange this with the right set-up. Also, I wouldn't be looking for 100% accuracy, even if it was only roughly it could be a significant improvement.Am 12.10.2009 20:33, schrieb Thorsten von Eicken:Thorsten von Eicken wrote:One further thought, instead of trying to allocate RRDs sequentially, if there is a way to query/detect where each RRD file is allocated on disk, then rrdcached could sort the dirty tree nodes by disk location and write them in that order. I don't know whether Linux (or FreeBSD) have a way to query disk location or to at least infer it.TvEEven though Linux and Windows (and I guess most other OSes) allow to query the "logical" disc position the physical location maybe completely unrelated to this as modern harddrives mayreallocate certain sectors if they feel that one particular sector cannot be read\written properly. Thus trying to infer the physical location of data will not be accurate. To take this even further not even the volume you write onto hast to exist physically, e.g. you might have a RAID or LVM in which case one logical sector corresponds to more than one physical location or as in cases of a RAM disc none at all (at least no permanent one). To make the picture complete there's even another factor that makes this nothing you want to do in software: Modern harddrives usually "plan" their read and write requests automatically already. So when write accesses occure right behind each other the harddrive will already figure out the best way to write them - unless you enforce synchronous request completion with e.g. O_DIRECT or thelike. TvE |
_______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers