[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