Darren J Moffat <darrenm@xxxxxxxxxxxxxxx> writes:
> That disables the ZIL for *all* datasets on *all* pools on the system.
> Doing this means that for NFS client or other applications (maybe
> local) that rely on the POSIX synchronus requirements of fsync they
> may see data loss on a crash. Note that the ZFS pool is still
> consistent on disk but the application that is flushing writes
> synchonusly may have missing data on recovery from the crash.
> NEVER turn off the ZIL other than for testing on dummy data whether or
> not the ZIL is your bottleneck. NEVER turn off the ZIL on live data
I think that is a bit too strong, I'd say "NEVER turn off the ZIL when
external clients depend on stable storage promises". that is, don't
turn ZIL off when your server is used for CIFS, NFS, iSCSI or even
services on a higher level, such as a web server running a storefront,
where customers expect a purchase to be followed through...
I've disabled ZIL on my server which is running our backup software
since there are no promises made to external clients. the backup jobs
will be aborted, and the PostgreSQL database may lose a few transactions
after the reboot, but I won't lose more than 30 seconds of stored data.
this is quite unproblematic, especially compared to the disruption of
the crash itself.
(in my setup I potentially have to manually invalidate any backup
jobs which finished within the last 30 seconds of the crash. this is
due to the database running on a different storage pool than the backup
data, so the point in time for the commitment of backup data and backup
metadata to stable storage may/will diverge. "luckily" the database
transactions usually take 30+ seconds, so this is not a problem in
of course, doing this analysis of your software requires in-depth
knowledge of both the software stack and the workings of ZFS, so I can
understand Sun^H^H^HOracle employees stick to the simple advice "NEVER
Kjetil T. Homme
Redpill Linpro AS - Changing the game
zfs-discuss mailing list