what happens to pool if ZIL dies on ZFS v14

[Martin Simmons]

>>>>> On Wed, 22 Sep 2010 10:19:22 -0700, David Brodbeck said:
> 
> On Wed, Sep 22, 2010 at 10:14 AM, David Brodbeck <gull at gull.us> wrote:
> > On Wed, Sep 22, 2010 at 6:00 AM, Martin Simmons <martin at lispworks.com> wrote:
> >>>>>>> On Tue, 21 Sep 2010 15:38:22 -0700, David Brodbeck said:
> >>>
> >>> If you don't have a separate log device, synchronous writes are very
> >>> slow with the ZIL enabled.  This isn't such a big deal unless you're
> >>> using NFS, where essentially every write is synchronous.
> >>
> >> Is that true for all versions of NFS?  In my experience (on 8.0-RELEASE),
> >> NFSv2 is indeed synchronous, but NFSv3 does asynchronous flushing (for a
> >> variety of different client OSes).
> >
> > It does allow clients to request asynchronous flushing.  My statement
> > that "essentially every write is synchronous" was a bit of an
> > overstatement; the problem comes when the client issues a COMMIT,
> > which happens frequently when doing some operations, such as
> > extracting tar files.  These are the operations that can get quite
> > slow when using NFS with the ZIL enabled and no separate log device.
> > By "quite slow," I mean several minutes to extract a tar file that
> > takes less than a minute with the ZIL disabled.
> 
> I should add that there's a very good, if somewhat
> OpenSolaris-centric, explanation of the issue here:
> http://blogs.sun.com/roch/entry/nfs_and_zfs_a_fine
> 
> The problem shows up more with ZFS because it enforces proper cache
> semantics, while many other filesystems do not.  This isn't always a
> satisfactory explanation to users who expect to be able to untar files
> in a reasonable amount of time, however. ;)

Thanks, I see what you mean.  FWIW, both Linux and FreeBSD 7.3 nfs clients
appear to be running asynchronously by default (zpool iostat 1 shows bursty
writes while extracting with tar), whereas Solaris 10 clients appear to be
doing very slow synchronous operations.

__Martin