On 12/22/2010 10:04 PM, Christopher George wrote:
How about comparing a non-battery backed ZIL to running a
ZFS dataset with sync=disabled. Which is more risky?
Most likely, the 3.5" SSD's on-board volatile (not power protected)
memory would be small relative to the transaction group (txg) size
and thus less "risky" than sync=disabled.
Best regards,
Christopher George
Founder/CTO
www.ddrdrive.com
To the OP: First off, what do you mean by "sync=disabled"??? There is
no such parameter for a mount option or attribute for ZFS, nor is there
for exporting anything in NFS, nor for client-side NFS mounts.
If you meant "disable the ZIL", well, DON'T.
http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Disabling_the_ZIL_.28Don.27t.29
Moreover, disabling the ZIL on a per-dataset basis is not possible.
As noted in the ETG, disabling ZIL can cause possible NFS-client-side
corruption. If you absolutely must turn it off, however, you will get
More Reliable transactions than a non-SuperCap'd SSD, by virtue that any
sync-write on such a fileserver will not return as complete until the
data has reach backing store. Which, in most cases, will tank (no pun
intended) your synchronous performance. About the only case it won't
cripple performance is when your backing store is using some sort of
NVRAM to buffer writes to the disks (as most large array controllers do
- but make sure that cache is battery backed). But even there, it can
be a relatively simple thing to overwhelm the very limited cache on such
a controller, in which case your performance tanks again.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
