<br>
<div><span class="gmail_quote">On 1/12/09, <b class="gmail_sendername">Daniel Phillips</b> <<a href="mailto:phillips@phunq.net">phillips@phunq.net</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Monday 12 January 2009 02:19, Michael Keulkeul wrote:<br>> Hi<br>><br>> Yes it does fail to guarantee consistency between filesystem<br>
> and application state, but it's a tool to guarantee it :<br>><br>> if you want to take a consistent snapshot of you database :<br>> 1- put your DB in backup mode, or make our app layer happy<br>> 2- freeze your FS<br>
> 3- sync everything<br>> 4- take a snapshot (of the block devices)<br>> 5- unfreeze FS<br>> 6- DB back in standard mode<br>><br>><br>> If you skip the freeze step, disk write still can happen between end of 3<br>
> and end of 4 so you can get dirty ondisk images.<br><br>What do you mean by dirty? Unwanted writes came from the DB, or unwanted<br>writes came from another application?</blockquote>
<div> </div>
<div>Mmm I think my exemple was not carefully chosen</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">If the former, then the DB was not really in backup mode. If the latter,<br>then the unwanted IO from another application could just as easily have<br>
occurred before freezing the FS.<br><br>> As discussed in a earlier<br>> thread, tux3 design should enable to "tux3freeze" a filesystem (get a clean<br>> ondisk image) without blocking writes (just throttle N io/sec until buffers<br>
> P% full, then return something and unfreeze).<br>><br>> And this would enable us to do something like this :<br>><br>> Repeat<br>> 1- put your DB in backup mode, or freeze app io/s...<br>> 2- tux3freeze your FS<br>
> 3- sync everything (maybe not necessary)<br>> 4- DB or app back in standard mode<br>> 5- take a snapshot (of the block devices)<br>> Until my fs still tux3freezed at that moment<br>> (not unfreeze as we go back to normal state when we're full)<br>
<br>But with Tux3's snapshot model, that is the same as:<br><br>1 - Put your DB in backup mode, or freeze app io/s...<br>2 - Set a Tux3 snapshot<br>3 - DB or app back in standard mode</blockquote>
<div> </div>
<div>OK, cool :)</div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">The snapshot will include the latest writes to disk, not include any<br>writes after the snapshot, and the snapshot command will not return<br>
until the snapshot has committed to disk. Meanwhile, IO from other<br>applications can continue, and it will go into the next snapshot. So<br>why have a freeze?</blockquote>
<div> </div>
<div>Mmm OK, I must admit it's not trivial, I perhaps took a bad exemple and my english is perhaps a bit short to make it clear. Let me try another time :)</div>
<div> </div>
<div>Let's suppose we've a SAN, and that we have a tux3 filesystem on a block device that support versionning. What we want to do is to get a stable ondisk image so we can mount it from another server without repair the filesystem nor replay some logs. To do that, your SAN backend needs a "snapshot window" with a start and a end : Filesystem must be stable during that time window no writes should occur and filesystem should be clean, that's exactly we have between the fs-freeze return and the launch of the fs-unfreeze.</div>
<div>But there is other solutions ! If we can check that no writes to disks occured during our "snapshot window" and that the filesystem was stable at the start of it we can get something less distruptive but less sure.</div>
<div> </div>
<div>Even if tux3 supports snapshots, be sure that admins will want to get stable hot tux3 block device images to be able to export it to other hosts (think backup or disaster recovery)</div>
<div> </div>
<div>If I understood correctly, freezing would be suspend next phase and the second method I described should be "staying in the same phase". For SAN admins, perfect thing would be to have both so they can decide between non-blocking-perhaps and blocking-for-sure !</div>
<div> </div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">By the way, are you thinking about a specific database, or databases in<br>general?</blockquote>
<div> </div>
<div>Database in general... I must confess that my mind was perhaps oracle oriented :)</div>
<div> </div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Regards,<br><br>Daniel<br></blockquote></div><br>