[Tux3] Generic filesystem freeze

[Michael Keulkeul]

On 1/12/09, Daniel Phillips <phillips at phunq.net> wrote:
>
> On Monday 12 January 2009 02:19, Michael Keulkeul wrote:
> > Hi
> >
> > Yes it does fail to guarantee consistency between filesystem
> > and application state, but it's a tool to guarantee it :
> >
> > if you want to take a consistent snapshot of you database :
> > 1- put your DB in backup mode, or make our app layer happy
> > 2- freeze your FS
> > 3- sync everything
> > 4- take a snapshot (of the block devices)
> > 5- unfreeze FS
> > 6- DB back in standard mode
> >
> >
> > If you skip the freeze step, disk write still can happen between end of 3
> > and end of 4 so you can get dirty ondisk images.
>
> What do you mean by dirty?  Unwanted writes came from the DB, or unwanted
> writes came from another application?


Mmm I think my exemple was not carefully chosen

If the former, then the DB was not really in backup mode.  If the latter,
> then the unwanted IO from another application could just as easily have
> occurred before freezing the FS.
>
> > As discussed in a earlier
> > thread, tux3 design should enable to "tux3freeze" a filesystem (get a
> clean
> > ondisk image) without blocking writes (just throttle N io/sec until
> buffers
> > P% full, then return something and unfreeze).
> >
> > And this would enable us to do something like this :
> >
> > Repeat
> >   1- put your DB in backup mode, or freeze app io/s...
> >   2- tux3freeze your FS
> >   3- sync everything (maybe not necessary)
> >   4- DB or app back in standard mode
> >   5- take a snapshot (of the block devices)
> > Until my fs still tux3freezed at that moment
> > (not unfreeze as we go back to normal state when we're full)
>
> But with Tux3's snapshot model, that is the same as:
>
> 1 - Put your DB in backup mode, or freeze app io/s...
> 2 - Set a Tux3 snapshot
> 3 - DB or app back in standard mode


OK, cool :)


The snapshot will include the latest writes to disk, not include any
> writes after the snapshot, and the snapshot command will not return
> until the snapshot has committed to disk.  Meanwhile, IO from other
> applications can continue, and it will go into the next snapshot.  So
> why have a freeze?


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 :)

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.
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.

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)

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 !



By the way, are you thinking about a specific database, or databases in
> general?


Database in general... I must confess that my mind was perhaps oracle
oriented :)


Regards,
>
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phunq.net/pipermail/tux3/attachments/20090112/457970e7/attachment-0001.html>
-------------- next part --------------
_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3