Date: Thu, 4 Jul 2013 20:36:45 -0600 From: Will Andrews <will@firepipe.net> To: Steven Hartland <killing@multiplay.co.uk> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: EBS snapshot backups from a FreeBSD zfs file system: zpool freeze? Message-ID: <CADBaqmjF8z37pVW_pPZHCeppWqvkLaWxEJT55iW9sme0i-kS9Q@mail.gmail.com> In-Reply-To: <BD8B4240539A46FC9FB86615A7F675CA@multiplay.co.uk> References: <87li5o5tz2.wl%berend@pobox.com> <BD8B4240539A46FC9FB86615A7F675CA@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 3, 2013 at 6:13 PM, Steven Hartland <killing@multiplay.co.uk> wrote: > Not been following the thread really so excuse if this has already > been mentioned ;-) > > There is a zpool freeze <pool> which stops spa_sync() from doing > anything, so that the only way to record changes is on the ZIL. > > The comment in the zpool_main is: "'freeze' is a vile debugging > abomination" so it's evil but might be what you want if you're up to > writing some code. zpool freeze is a debugging-only command, as the comment suggests. It is not really of much use outside of testing changes to ZIL code. Once run, the only thing you can do to get normal I/O running again is to export the pool and import it again. The point of the command is to ensure that ZIL blocks exist on a pool when it is exported, so they are guaranteed to have to be replayed on import. It is used in the STF test suite for the express purpose of testing the ZIL replay. They write some stuff, freeze the pool, write some more stuff, export the pool, use zdb to check for ZIL blocks, then import it and check again, both to see that the changes were applied, and to see that the ZIL blocks are gone. Most likely, doing something more like Berend wants requires a slightly different approach. --Will.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADBaqmjF8z37pVW_pPZHCeppWqvkLaWxEJT55iW9sme0i-kS9Q>