Right on. And you might want to capture this in a blog for
reference. The permalink will be quite useful.
We did have a use case for zil synchronicity which was a
big user controlled transaction :
turn zil off
do tons of thing to the filesystem.
big sync
turn zil back on
[ ] Rename or remove zil_disable
[x] Implement zil synchronicity.
[ ] I see no problem the way it is currently.
As for a DB, if the log and data are on different pools (our
current best practice) then I guess that DB corruption is
still possible with zil_disable. With the case of DB on a
single pool but different filesystems, better insure you
have the same setting for both.
Notification of the Completion of a transtion may also leave
the bound of the host system. Never use zil_disable there.
This last issue applies to an NFS server. I have blog entry
coming up on that.
-r
Anton B. Rang writes:
> > Also, (Richard can address this better than I) you may want to disable
> > the ZIL or have your array ignore the write cache flushes that ZFS issues.
>
> The latter is quite a reasonable thing to do, since the array has
> battery-backed cache.
>
> The ZIL should almost [b]never[/b] be disabled. The only reason I can
> think of is to determine whether a performance issue is caused by the
> ZIL.
>
> Disabling the ZIL does not only disable the intent log; it also causes
> ZFS to renege on the contract that fsync(), O_SYNC, and friends ensure
> that data is safely stored. A mail server, for instance, relies on
> this contract to ensure that a message is on disk before acknowledging
> its reception; if the ZIL is disabled, incoming messages can be lost
> in the event of a system crash. A database relies on this contract to
> ensure that its log is on disk before modifying its tables; if the ZIL
> is disabled, the database may be damaged and uncoverable in the event
> of a system crash.
>
> The ZIL is a necessary part of ZFS. Just because the ZFS file
> structure will be consistent after a system crash even with the ZIL
> disabled does not mean that disabling it is safe!
>
>
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
