Date: Wed, 3 Jul 2013 22:15:50 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-fs <freebsd-fs@FreeBSD.org> Subject: Re: EBS snapshot backups from a FreeBSD zfs file system: zpool freeze? Message-ID: <20130703215557.U26322@besplex.bde.org> In-Reply-To: <20130703073333.GA57318@icarus.home.lan> References: <87li5o5tz2.wl%berend@pobox.com> <CA%2BtpaK1jQuKneQsxkVfxJGzXdPdLZfqBM1QWQ0e19nK5t71t1Q@mail.gmail.com> <87ehbg5raq.wl%berend@pobox.com> <20130703055047.GA54853@icarus.home.lan> <6488DECC-2455-4E92-B432-C39490D18484@dragondata.com> <CADBaqmihCB5JP01hLwXTWHoZiJJ5-jkT-Ro=oDwOcKZT_zvEKA@mail.gmail.com> <20130703073333.GA57318@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130703215557.U26322>