Actually - I can't read ZFS code, so the next assumtions are more or less based
on brainware - excuse me in advance :)
How does ZFS detect "up to date" zil's ? - with the tnx check of the ueberblock
- right ?
In our corruption case, we had 2 valid ueberblocks at the end and ZFS used
those to import the pool. this is what the end-ueberblock is for. Ok, so the
ueberblock contains the pointer to the start of the zil chain - right ?
Assume we are adding the tnx number of the current transaction this zil is part
of to the blocks written to the zil (special packages zil blocks). So the zil
blocks are a little bit bigger then the data blocks, however the transaction
count is the the same. Ok for SSD block alignment might be an issue ... agreed.
For memory DRAM based ZIL's this is not a problem - except for bandwith.
Logic:
On ZIL import, check:
- If the pointer to the zil chain is empty
if yes -> clean pool
if not -> we need to replay
- now if the block the root pointer points to is ok (checksum), the zil is
used and replayed. At the end, the tnxof the last zil block must be = pool tnx.
If =, then OK, if not report a error about missing zil parts and switch to
mirror (if available).
> As Neil outlined, this isn't possible while
> preserving current ZIL performance. There is no way
> to distinguish the "last" ZIL block without incurring
> additional writes for every block. If it's even
> possible to implement this "paranoid ZIL" tunable,
> are you willing to take a 2-5x performance hit to be
> able to detect this failure mode?
>
Robert
--
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
