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. 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) On 1/12/09, Daniel Phillips <[email protected]> wrote: > > On Sunday 11 January 2009 23:57, Michael Keulkeul wrote: > > Hi all > > > > I don't know if you already know, but generic filesystem freeze interface > is > > being add to linux kernel, check linux 2.6.29-rc1 changelog for more > info. > > > > Best regards > > > > Michael B. > > We will certainly support it, but note my skepticism about the value > of it. It certainly fails to gaurantee consistency between filesystem > and application state, and it does introduce deadlock risk, so I am not > sure what it is for. Please enlighten me :-) > > Regards, > > Daniel >
_______________________________________________ Tux3 mailing list [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
