[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