On Tue, Feb 24, 2009 at 10:41 AM, Christopher Mera <cm...@reliantsec.net> wrote:
> 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
>

If you are writing a script to handle ZFS snapshots/backups, you could
issue an SMF command to stop the service before taking the snapshot.
Or at the very minimum, perform an SQL dump of the DB so you at least
have a consistent full copy of the DB as a flat file in case you can't
stop the DB service.


-- 
Brent Jones
br...@servuhome.net
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to