zfs l2arc warmup

[Freddie Cash]

On Fri, Mar 28, 2014 at 2:19 PM, Dmitry Morozovsky <marck at rinet.ru> wrote:

> On Fri, 28 Mar 2014, Freddie Cash wrote:
>
> [snip most again]
>
> > Around ZFSv14-ish, the ability to import a pool with a missing ZIL was
> > added.
> >
> > Remember the flow of data in ZFS:
> >   async write request --> TXG --> disk
> >   sync write request --> ZIL
> >                \--> TXG --> disk
> >
> > All sync writes are written to the pool as part of a normal async TXG
> after
> > its written sync to the ZIL.  And the ZIL is only ever read during pool
> > import.
>
> On the other side, doesn't it put the risk on sync-dependent, like
> database,
> systems?
>
> I'm thinking not about losing the transaction, but possibly putting your
> filesystem in the middle of (database PoV) transaction, hence render your
> DB
> inconsistent?
>
> Quick googling seems to be uncertain about it...
>

​That I don't know.  Again, I'm not a ZFS code guru; just a very
happy/active ZFS user and reader of stuff online.  :)

You're thinking of the small window where:
  - database writes transaction to disk
  - zfs writes ​the data to the ZIL on the log vdev
  - zfs returns "data is written to disk" to the DB
  - zfs queues up the write to the pool
  - the log device dies
  - the pool is forcibly exported/server loses power

Such that the DB considers the transaction complete and the data safely
written to disk, but it's actually only written to the ZIL on the separate
log device (which no longer exists) and is not stored in the pool yet.

Yeah, that could be a problem.  A very unlikely event, although not
entirely impossible.

​I would think it would be up to the database to be able to roll-back a
database to prior to the corrupted transaction.  If the DB has a log or
journal or whatever, then it could be used to roll-back, no?

It's still considered best practice to use mirror log device.  It's just no
longer required, nor does a dead log lead to a completely dead pool.​

-- 
Freddie Cash
fjwcash at gmail.com