Either way - it would be ideal to quiesce the system before a snapshot anyway,
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.
From: Mattias Pantzare [mailto:pantzare@xxxxxxxxx]
Sent: Tuesday, February 24, 2009 1:38 PM
To: Nicolas Williams
Cc: Christopher Mera; zfs-discuss@xxxxxxxxxxxxxxx
Subject: Re: [zfs-discuss] zfs streams & data corruption
On Tue, Feb 24, 2009 at 19:18, Nicolas Williams
> 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