<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><style>.EmailQuote {
        BORDER-LEFT: #800000 2px solid; PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt
}
</style>

<style id="owaParaStyle">P {
        MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body ocsi="0" fPStyle="1">
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 13px">
<div>I had a bit of a hack with the rrdcached code yesterday; I added in a PAUSE and RESUME command which temporarily stops and restarts the write threads while still accepting (and queueing) the pending updates, so that nothing is lost during the backups.</div>
<div>&nbsp;</div>
<div>Its still rather rough and (1) it pauses EVERYTHING so you have to watch how big the in-memory queue gets, and (2) during my test, there were 10,000&#43; updates queued over a 20min pause, but for some reason 4 writes were still done.&nbsp; I haven't yet found out why.&nbsp; So, its not stable yet, though it's definitely got possibilities.&nbsp; I can send you a copy of the modified code if you want though I'd certinaly not advise putting it into a production environment yet!</div>
<div>&nbsp;</div>
<div>Steve</div>
<div><br>
<div style="FONT-FAMILY: Tahoma; FONT-SIZE: 13px">
<div style="FONT-FAMILY: Tahoma; FONT-SIZE: 13px"><strong>Steve Shipway</strong></div>
<div style="FONT-FAMILY: Tahoma; FONT-SIZE: 13px">University of Auckland ITS</div>
<div style="FONT-FAMILY: Tahoma; FONT-SIZE: 13px"><em>UNIX Systems Design Lead</em></div>
<div style="FONT-FAMILY: Tahoma; FONT-SIZE: 13px"><a href="mailto:s.shipway@auckland.ac.nz" target="_blank">s.shipway@auckland.ac.nz</a></div>
<div style="FONT-FAMILY: Tahoma; FONT-SIZE: 13px">Ph: &#43;64 9 373 7599 ext 86487</div>
<div style="FONT-FAMILY: Tahoma; FONT-SIZE: 13px"><em></em>&nbsp;</div></div></div>
<div>
<hr tabindex="-1">

<div id="x_divRplyFwdMsg"><font color="#000000" size="2" face="Tahoma"><b>From:</b> Jochen Bern [Jochen.Bern@LINworks.de]<br><b>Sent:</b> Wednesday, 27 October 2010 9:08 p.m.<br><b>To:</b> rrd-users@lists.oetiker.ch<br><b>Cc:</b> Steve Shipway<br><b>Subject:</b> Re: [rrd-users] Locking *read* (copy/backup) of RRD files?<br></font><br></div>
<div></div></div><font size="2"><span style="FONT-SIZE: 10pt">
<div class="PlainText">On 10/27/2010 02:32 AM, Steve Shipway wrote:<br>&gt; however I'd use a filesystem snapshot so the time during which the<br>&gt; rrdcached is inoperative would be measured in seconds<br><br>That is, of course, the authoritative solution to the problem of doing<br>full backups - and would require a full reinstall in my case because a<br>need for snapshot capability wasn't anticipated at OS install time. :-}<br>(Someone else did it, resulting in ext3 on LVM with no unused physical<br>extents ...)<br><br>However, it's not too difficult to imagine scenarios where one would<br>*still* want consistent duplication on a single-RRD-file level; e.g.,<br>thanks to n2rrd in full auto mode, I get to go through the cycle of<br>rrddump;vi;mv;rrdrestore every now and then to remove bogus DSs ...<br><br>&gt;&gt; As a matter of fact, I'm a bit surprised to see that rrdresize seems to<br>&gt;&gt; be the *only* part of rrdtool which sets a(ny) lock while *reading* an<br>&gt;&gt; RRD file.<br>&gt; I'd need to check, but possibly since the RRD file size is constant<br>&gt; (except when running rrdresize) it means that since reads and writes<br>&gt; are atomic, the reads do not need to be locked as you will always get<br>&gt; consistent data?<br><br>In 1.4.4 src/rrd_open.c::rrd_open(), I see eight __rrd_read() ; these<br>read out of an mmap() if available, and do an actual read() else. My<br>mmap(2) manpage (OpenSuSE 11.2) warns me that it &quot;is unspecified whether<br>changes made to the file after the mmap() call are visible in the mapped<br>region&quot;, not to even dream about any kind of atomicity ...<br><br>Kind regards,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; J. Bern<br>-- <br>Jochen Bern, Systemingenieur --- LINworks GmbH &lt;<a href="http://www.linworks.de/" target="_blank">http://www.LINworks.de/</a>&gt;<br>Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt<br>PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27<br>Tel. &#43;49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202<br>Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel<br></div></span></font></div></body></html>