> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
> As for ZIL - even if it is used with the in-pool variant, I don't
> think your setup needs any extra steps to disable it (as Edward likes
> to suggest), and most other setups don't need to disable it either.

No, no - I know I often suggest disabling the zil, because so many people 
outrule it on principle (the evil tuning guide says "disable the zil (don't!)")

But in this case, I was suggesting precisely the opposite of disabling it.  I 
was suggesting making it more aggressive.

But now that you mention it - if he's looking for maximum performance, perhaps 
disabling the zil would be best for him.   ;-)  

Nathan, it will do you some good to understand when it's ok or not ok to 
disable the zil.   (zfs set sync=disabled)  If this is a guest VM in your 
laptop or something like that, then it's definitely safe.  If the guest VM is a 
database server, with a bunch of external clients (on the LAN or network or 
whatever) then it's definitely *not* safe.

Basically if anything external of the VM is monitoring or depending on the 
state of the VM, then it's not ok.  But, if the VM were to crash and go back in 
time by a few seconds ... If there are no clients that would care about that 
... then it's safe to disable ZIL.  And that is the highest performance thing 
you can possibly do.

> It also shouldn't add much to your writes - the in-pool ZIL blocks
> are then referenced as userdata when the TXG commit happens (I think).

I would like to get some confirmation of that - because it's the opposite of 
what I thought.  
I thought the ZIL is used like a circular buffer.  The same blocks will be 
overwritten repeatedly.  But if there's a sync write over a certain size, then 
it skips the ZIL and writes immediately to main zpool storage, so it doesn't 
have to get written twice.

> I also think that with a VM in a raw partition you don't get any
> snapshots - neither ZFS as underlying storage ('cause it's not),
> not hypervisor snaps of the VM. So while faster, this is also some
> trade-off :)

Oh - But not faster than zvol.  I am currently a fan of wrapping zvol inside 
vmdk, so I get maximum performance and also snapshots.

zfs-discuss mailing list

Reply via email to