Either way - it would be ideal to quiesce the system before a snapshot anyway, no?
My next question now is what particular steps would be recommended to quiesce a system for the clone/zfs stream that I'm looking to achieve... All your help is appreciated. Regards, Christopher Mera -----Original Message----- From: Mattias Pantzare [mailto:pantz...@gmail.com] Sent: Tuesday, February 24, 2009 1:38 PM To: Nicolas Williams Cc: Christopher Mera; zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] zfs streams & data corruption On Tue, Feb 24, 2009 at 19:18, Nicolas Williams <nicolas.willi...@sun.com> wrote: > On Mon, Feb 23, 2009 at 10:05:31AM -0800, Christopher Mera wrote: >> I recently read up on Scott Dickson's blog with his solution for >> jumpstart/flashless cloning of ZFS root filesystem boxes. I have to say >> that it initially looks to work out cleanly, but of course there are >> kinks to be worked out that deal with auto mounting filesystems mostly. >> >> The issue that I'm having is that a few days after these cloned systems >> are brought up and reconfigured they are crashing and svc.configd >> refuses to start. > > When you snapshot a ZFS filesystem you get just that -- a snapshot at > the filesystem level. That does not mean you get a snapshot at the > _application_ level. Now, svc.configd is a daemon that keeps a SQLite2 > database. If you snapshot the filesystem in the middle of a SQLite2 > transaction you won't get the behavior that you want. > > In other words: quiesce your system before you snapshot its root > filesystem for the purpose of replicating that root on other systems. That would be a bug in ZFS or SQLite2. A snapshoot should be an atomic operation. The effect should be the same as power fail in the meddle of an transaction and decent databases can cope with that. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
