[OmniOS-discuss] Status of TRIM support?

Bob Friesenhahn bfriesen at simple.dallas.tx.us
Wed May 28 02:22:00 UTC 2014


On Tue, 27 May 2014, Dan Swartzendruber wrote:

>
> So I've been running with sync=disabled on my vsphere NFS datastore.  I've
> been willing to do so because I have a big-ass UPS, and do hourly backups.
> But, I'm thinking of going to an active/passive connection to my JBOD,
> using Saso's blog post on zfs zfs-create.blogspot.com.  Here's why I think
> I can't keep using sync=disabled (I would love to have my logic sanity
> checked.)  If you switch manually from host A to B, all is well, since

Zfs does not depend on sync writes ('zil') for pool integrity.  It 
does depend on cache flush across all disks for pool integrity.  The 
harm from sync=disabled is that when the system comes back up, the 
data may not be coherent from the application's perspective (lost 
transactions, part of the written file incorrect/missing).  Your 
'vsphere' fits in the realm of applications.

If zfs imports the pool, it will choose the latest transaction group. 
The zfs cache flush is done on all the disks before it writes the new 
transaction group id (in a separate transaction).  If there is somehow 
still something wrong, it is possible to import using an older 
transaction group (losing more recent data).

Note that the latest transaction group might be from five minutes ago.

The big-ass UPS helps, but is not a fool-proof solution since 
something else (hardware, OS, or power) might fail.

It looks to me like Sašo's design is active/standby failover.  Zpool 
import on the standby should obtain a clean transaction group as long 
as the originally active system is still not using the pool.  The 
result would be similar to the power fail situation.

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


More information about the OmniOS-discuss mailing list