zfs l2arc warmup

[Dmitry Morozovsky]

On Fri, 28 Mar 2014, Freddie Cash wrote:

> > > > Have you measured to see if, or do you otherwise know for sure, that
> > you
> > > > really do need a ZIL? I suggest not adding a ZIL unless you are certain
> > > > you need it.
> > > Yes, I only recently realized that too, and I'm really not sure if a
> > > zil is required.
> > > Some small portion of files (som hundre MB's) are served over nfs from
> > > the same server, if I understand it right a zil will help for nfs
> > > stuff (?) , but I'm not sure if it's any gain of having a zil today.
> > > On the other hand, a zil doesn't have to be big, I can simply buy a
> > > 128GB ssd which are cheap today .
> >
> > Please don't forget that, unlike L2ARC, if you lost ZIL during sync write,
> > you're effectively lost the pool.
> >
> 
> ?Nope.  Not even close.
> 
> The ZIL is only ever read at boot time.  If you lose the ZIL between the
> time the data is written to the ZIL and the time the async write of the
> data is actually done to the pool ... and the server is rebooted at that
> time, then you get an error message at pool import.
> 
> You can then force the import of the pool, losing any *data* in the ZIL,
> but nothing else.
> 
> It used to be (back in the pre-ZFSv?13-ish days) that if you lost the ZIL
> while there was data in it that wasn't yet written to the pool, the pool
> would fault and be gone.  Hence the rule-of-thumb to always mirror the ZIL.
> 
> 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.
> 
> ?[Note, I'm not a ZFS developer so some of the above may not be 100%
> accurate, but the gist of it is.]?

Ah, thanks, I stand corrected.

Great we're tighten the window we could possibly lose precious data.

-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck at FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru ***
------------------------------------------------------------------------