From owner-freebsd-fs@FreeBSD.ORG Wed Jul 3 12:16:04 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 323D5291 for ; Wed, 3 Jul 2013 12:16:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id B0A711792 for ; Wed, 3 Jul 2013 12:16:03 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 81E9E3C1ECF; Wed, 3 Jul 2013 22:15:54 +1000 (EST) Date: Wed, 3 Jul 2013 22:15:50 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jeremy Chadwick Subject: Re: EBS snapshot backups from a FreeBSD zfs file system: zpool freeze? In-Reply-To: <20130703073333.GA57318@icarus.home.lan> Message-ID: <20130703215557.U26322@besplex.bde.org> References: <87li5o5tz2.wl%berend@pobox.com> <87ehbg5raq.wl%berend@pobox.com> <20130703055047.GA54853@icarus.home.lan> <6488DECC-2455-4E92-B432-C39490D18484@dragondata.com> <20130703073333.GA57318@icarus.home.lan> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1674810795-1372853750=:26322" X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=eqSHVfVX c=1 sm=1 a=_L_Mgjhap9MA:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=Xp-57ecbnGcA:10 a=6I5d2MoRAAAA:8 a=088zp9679ETcpNnLNjMA:9 a=45ClL6m2LaAA:10 a=sJYPmuLzIcQA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 12:16:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1674810795-1372853750=:26322 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE 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 transacti= ons >> 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 =C3=BCberblock down in ZFS is COW, yo= u 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 --0-1674810795-1372853750=:26322--