[OmniOS-discuss] Auto snapshots?

[Sašo Kiselkov]

On 04/23/2013 05:26 PM, Eric Sproul wrote:
> On Tue, Apr 23, 2013 at 11:12 AM, Sašo Kiselkov <skiselkov.ml at gmail.com> wrote:
>> Quiescing clients is something that's been kicking around my head for a
>> while and I'm not sure ZFS per-se needs it. The canonical example of a
>> customer who needs transactional consistency are databases. Those
>> already implement their own redo logs, so all one needs to ensure is
>> that a snapshot is taken in between atomic updates by the database (e.g.
>> when committing a redo log entry). This should, in theory, align well
>> with ZFS transaction groups - a txg is either in a snapshot completely,
>> or not at all. So even if the full DB transaction (think BEGIN/COMMIT)
>> is partly split up between ZFS txg's, it's the COMMIT step that must be
>> atomic, and as far as I can see it, it is.
>>
>> If not, where did I go wrong?
> 
> Databases are already aware that their storage is unreliable, and act
> accordingly.  It's true that over NFS, those guest writes from ESXi
> are typically sync, and so are flushed out to either an SSD SLOG or
> the main pool, and given that txg's cannot span snapshot boundaries,
> you can be reasonably assured that what the guest committed is
> actually in the snapshot.

Interesting, so it would seem that for most workloads (or at least those
that implement some sort of transaction-aware storage in the
application), backup agents would be useless.

As for ESXi, it can also work in sync mode over iSCSI, but you need to
set your LUNs up so that they don't advertise a non-volatile cache. Then
ESXi will issue all SCSI commands as "sync-immediate" commands, which
then hits your ZIL (which can be off-loaded to an SSD). When dealing
with "opaque LUNs" (physical RDM in ESXi-speak), this responsibility
moves to the VM.

Cheers,
--
Saso