<br><br>
<div><span class="gmail_quote">On 1/8/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 Wednesday 07 January 2009 07:21, OGAWA Hirofumi wrote:<br>> Daniel Phillips <<a href="mailto:phillips@phunq.net">phillips@phunq.net</a>> writes:<br>
><br>> >> Filesystem freeze :<br>> >> Get an utility that flush cache and return something when it's done, then<br>> >> freeze IO on disk and throttle/stack in a memory buffer until it's full.<br>
> >> When it's full, return again something and resume normal operation, or<br>> >> freeze IO until we ask to resume. This in order to take clean snapshots when<br>> >> backend support versionning. Even if it's not necessary due to tux3 design,<br>
> >> it would be nice to be able to do it in order to ensure that some IO are<br>> >> commited to disk, then get some time to do something to the disk backend,<br>> >> with no impact on the filesystem side.<br>
> ><br>> > I think all you want there is the ability to treat a snapshot as a<br>> > barrier: user asks for a snapshot, Tux3 starts a new delta and sets a<br>> > flag on it; when that snapshot has committed, the snapshot request<br>
> > is acknowledged.  That way, the user gets a snapshot of what has been<br>> > sent to the filesystem most recently, without needing to stall the<br>> > filesystem throughput.<br>> ><br>> > Tux3 does not need a new memory buffer for this, the needed mechanism<br>
> > is just what has already been designed.<br>><br>> FWIW, if it is needed, we just implement ->write_super_lockfs nad unlockfs.<br>> And I guess it shouldn't be hard.<br><br>Yes, we will support lock/unlockfs.  I think he was asking for something<br>
a little different.  IO is supposed to continue to memory while block IO<br>is prevented, to take a clean snapshot.  We can do that better.  I think<br>What he really wants is for the snapshot to include the most recent<br>
changes, and not stall the filesystem.  lockfs causes a big stall and<br>danger of system lockup too.</blockquote>
<div> </div>
<div>Yes exactly ! <br> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">What we can provide instead is a command to set a new delta<br>that carries a new volume version.  All changes after that delta belong<br>
to the next snapshot.  When the delta that carries the snapshot completes<br>to disk, the snapshot setting command returns.  This way, the user gets<br>exactly what they expect: whatever they wrote before the snapshot ends<br>
up on disk.  And the only thing that stalls is the snapshot command: if<br>there is parallel IO on the filesystem, it will continue and belong to<br>the next snapshot.</blockquote>
<div> </div>
<div>Very cool, my explanation was apparently clear enought or you can access my brain's filesystem :)</div>
<div>(If the second hypothesis is the good one please share the access with my wife)</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Contrary to popular belief, lockfs does not make snapshots "clean".<br>Parallel application IO can be interrupted at any point by lockfs.<br>
There is nothing clean about that.  The only way to make a clean<br>snapshot with respect to application IO is for applications to be aware<br>of the snapshot interface and prepare themselves accordingly.  Because<br>there is no standard interface, no applications do that.  So lockfs does<br>
not produce any cleaner results than just taking a snapshot at some<br>random time.  What it does do, is flush dirty cache to disk before the<br>snapshot.  Another way to do that is sync(1), without danger of system<br>lockup.  So I don't know what lockfs is actually supposed to accomplish.</blockquote>

<div> </div>
<div>Yes, but if I'm not mistaken sync does not hold IO's to disk until you decide to release them, so if you don't have a filesystem freeze feature to hold them, bad things still can happen if you're hammering block devices with requests (most common case in fact). if you host Databases on the filesystem, it's very important to have that feature to be able to syncronize the snapshot with the application layer, and getting consistant database in snapshots is crutial otherwise versioning isn't really interesting.</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</blockquote>
<div> </div>
<div>Having this little tool can greatly increase tux3 popularity in enterprise class applications.</div>
<div>And this is a cool futur proof feature for a feature.</div>
<div>Tux3-clustered, even with lilmitations, would be the "cerise sur le gāteau" that would really put this filesystem ahead of others :)</div>
<div> </div>
<div>Best regards</div>
<div> </div>
<div>Michael</div>
<div> </div>
<div> </div>
<div> </div><br> </div>