what happens to pool if ZIL dies on ZFS v14

[David Brodbeck]

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. ;)