[OmniOS-discuss] Status of TRIM support?

Dan Swartzendruber dswartz at druber.com
Wed May 28 02:57:10 UTC 2014


cked.)  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.

Sorry if I was unclear.  Yes, I understand the above point. In the
scenario I referenced, data could fail to be written to a file (or
directory even worse), with no indication whatsoever, since if the
failover happens quickly enough vsphere will consider the delay to be ok.

> 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.

That was my understanding, yes.



More information about the OmniOS-discuss mailing list