This is purely tactical, to avoid l2arc write penalty on eviction. You seem to have missed the very next paragraph:
3644 * 2. The L2ARC attempts to cache data from the ARC before it is evicted. 3645 * It does this by periodically scanning buffers from the eviction-end of 3646 * the MFU and MRU ARC lists, copying them to the L2ARC devices if they are 3647 * not already there. Regards, Andrey On Sat, Mar 6, 2010 at 3:58 PM, Henrik Johansson <henr...@henkis.net> wrote: > Hello, > > On Mar 5, 2010, at 10:46 AM, Abdullah Al-Dahlawi wrote: > > Greeting All > > I have create a pool that consists oh a hard disk and a ssd as a cache > > zpool create hdd c11t0d0p3 > zpool add hdd cache c8t0d0p0 - cache device > > I ran an OLTP bench mark to emulate a DMBS > > One I ran the benchmark, the pool started create the database file on the > ssd cache device ??????????? > > > can any one explain why this happening ? > > is not L2ARC is used to absorb the evicted data from ARC ? > > > No, it is not. if we look in the source there is a very good description of > the L2ARC behavior: > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c > > "1. There is no eviction path from the ARC to the L2ARC. Evictions > from the ARC behave as usual, freeing buffers and placing headers on > ghost lists. The ARC does not send buffers to the L2ARC during eviction > as this would add inflated write latencies for all ARC memory pressure." > > Regards > > Henrik > http://sparcv9.blogspot.com > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
