EBS snapshot backups from a FreeBSD zfs file system: zpool freeze?

[Bruce Evans]

On Wed, 3 Jul 2013, Jeremy Chadwick wrote:

> On Wed, Jul 03, 2013 at 12:53:13AM -0600, Will Andrews wrote:
>> ...
>> This is because sync in ZFS is implemented as a ZIL commit, so transactions
>> that haven't yet made it to disk via the normal syncing context will at
>> least be committed via their ZIL blocks. Which can then be replayed when
>> the pool is imported later, in this case from the EBS snapshots.
>>
>> And since the entire tree from the überblock down in ZFS is COW, you can't
>> get an inconsistent pool simply by doing a virtual disk snapshot,
>> regardless of how that is implemented.
>
> I'm a little confused about this statement, particularly as a result of
> this thread (read the entire thing time permitting):
>
> http://lists.freebsd.org/pipermail/freebsd-fs/2013-April/016982.html
>
> UFS is what's being discussed there, but there are some blanket
> statements (maybe I'm taking them out of context, not entirely sure)
> made by Bruce there that seem to imply that sync(2) may not actually
> flush all memory buffers to disk when issued, only that they're
> "scheduled" to be flushed.

That was for ffs.

> ...
> So all this makes me wonder: why exactly does sync(2) result in
> different behaviour on UFS than it does on ZFS?  Do both of these
> filesystems not use BIO_write() and friends?  Does sync(2) not simply
> iterate over all the queued BIO_write()s and BIO_FLUSH them all?

ffs uses the buffer cache, and zfs doesn't go anywhere near the buffer
cache (it calls driver i/o routines fairly directly, via geom).  This
alone gives very different behaviour.  But zfs is even more different
for sync(2).

> Sorry if I'm overthinking this or missing something, but I just don't
> understand why sync(2) would flush stuff to disk with one filesystem but
> not another.

It is because zfs ignores sync(2)'s request to not wait for the i/o to
complete.

I don't know much else about zfs.

Bruce