[OpenIndiana-discuss] slicing a disk for ZIL

[Jim Klimov]

On 2012-11-29 17:29, Sebastian Gabler wrote:
> The data that will be affected are for test databases.
>
> As far as I am aware, the loss of the ZIL is no longer fatal for the
> pool in current zfs versions. As well, even with a corrupted ZIL, the
> pool should be recoverable. Hence, I was so far not worried too much.
> Should I better be?

For test databases - probably little worry. If your storage's power goes
down, your test database server would likely reboot too, and restart its
work from the available consistent disk state (which might not be the
latest data that the clients thought was saved). If you can reboot every
device and client which relies on the same view of the data, and if you
can safely ignore losing a few transactions - this setup should be ok.

The potential problems are for production systems which can not lose
transactions (i.e. eshop or bank databases), and for systems which rely
on files being saved to disk (mail servers, document workflow, etc.)

As for possible ZIL problems, they are as follows: the separate SLOG
saves sync parts of the ZFS transactions. When a transaction group (TXG)
closes, the same data and more (async data) is saved to main pool from
RAM dirty pages in cache. Thus the dedicated ZIL device is normally
only written, and very rarely read (after an unclean shutdown and the
following pool import). If it gets broken during work, ZFS detects
this state and falls back to using some blocks on the main pool for
ZIL tasks - as it does normally without a SLOG. The possible problems
are if the ZIL device is unmirrored and gets broken during such
poweroff - then the last group of transactions (possibly, a couple
of groups) which were not spooled to main pool disks can get lost.
Anyhow, any async data is also lost - but storage makes no guarantees
about storing that across powerloss and other breakages either, and
the clients should not expect async data to be safely stored (hence
the explicit sync IO requests or "flush" after async IO).

//Jim