[rrd-users] Locking *read* (copy/backup) of RRD files?

[Jochen Bern]

On 10/27/2010 02:32 AM, Steve Shipway wrote:
> however I'd use a filesystem snapshot so the time during which the
> rrdcached is inoperative would be measured in seconds

That is, of course, the authoritative solution to the problem of doing
full backups - and would require a full reinstall in my case because a
need for snapshot capability wasn't anticipated at OS install time. :-}
(Someone else did it, resulting in ext3 on LVM with no unused physical
extents ...)

However, it's not too difficult to imagine scenarios where one would
*still* want consistent duplication on a single-RRD-file level; e.g.,
thanks to n2rrd in full auto mode, I get to go through the cycle of
rrddump;vi;mv;rrdrestore every now and then to remove bogus DSs ...

>> As a matter of fact, I'm a bit surprised to see that rrdresize seems to
>> be the *only* part of rrdtool which sets a(ny) lock while *reading* an
>> RRD file.
> I'd need to check, but possibly since the RRD file size is constant
> (except when running rrdresize) it means that since reads and writes
> are atomic, the reads do not need to be locked as you will always get
> consistent data?

In 1.4.4 src/rrd_open.c::rrd_open(), I see eight __rrd_read() ; these
read out of an mmap() if available, and do an actual read() else. My
mmap(2) manpage (OpenSuSE 11.2) warns me that it "is unspecified whether
changes made to the file after the mmap() call are visible in the mapped
region", not to even dream about any kind of atomicity ...

Kind regards,
								J. Bern
-- 
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel