zfs discuss - Oct 2012 - What is L2ARC write pattern?

Hello all,

   A few months ago I saw a statement that L2ARC writes are simplistic
in nature, and I got the (mis?)understanding that some sort of ring
buffer may be in use, like for ZIL. Is this true, and the only metric
of write-performance important for L2ARC SSD device is the sequential
write bandwidth (and IOPS)? In particular, there are some SD/MMC/CF
cards for professional photography and such, that can do pretty good
bursts at writes, and may be okay (better than HDD) at random reads
of the cached blocks.

   Are such cards fit for L2ARC uses?

   One idea I have is that a laptop which only has a single HDD slot,
often has SD/MMC cardreader slots. If populated with a card for L2ARC,
can it be expected to boost the laptop''s ZFS performance?

   Also, what''s the worst that is expected to happen if the card pops
out of its cardreader slot while it is used as L2ARC - should the
ZFS filesystem panic or fall back to HDD data seamlessly? Or does it,
as always, depend on firmware and drivers involved in the stack?

Thanks,
//Jim

2012-10-22 20:58, Brian wrote:
> hi jim,
>
> writes are sequential and to a ring buffer.  reads of course would not
> be sequential, and would be intermixed with writes.
Thanks... Do I get it correctly that if a block from L2ARC is
requested by the readers, then it is fetched from the SSD and
becomes a normal block in the ARC - thus the L2ARC entry won''t
be used again for this same block when it expires again from
RAM ARC? Likewise, if the ring buffer is filled up and the
block in L2ARC becomes overwritten, a possible read via the
pointer from ARC to L2ARC fails (checksum mismatch), the pointer
gets invalidated and pool disks get used to read the data from
original source - right? If that all is the case, is there any
sort of "proactive" expiration of values from L2ARC, or it is
just not needed (useful data will travel from L2ARC to ARC and
back again, and useless data will expire by being overwritten
as the ring buffer completes its full cycle)?



 > the digital
> photography cards probably aren''t the fastest flash around, and
may not
> be designed for a high number of (over)write cycles, but anything that
> can be configured as a vdev ought to work as l2arc.
Well, I do photograph a lot and the consumer-grade cards begin
to show deterioration in a couple of years of use. AFAIK the
professional expensive ones also employ redundancy chips and
thus improve speed and reliability - being more of an SSD in
a non-SATA package ;)
>
> can''t say how the system will behave if the flash is yanked during
i/o.
> all the modules involved should handle that condition cleanly but it
> doesn''t mean the use case will work.
:)

Thanks,
//Jim

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Jim Klimov
> 
>    One idea I have is that a laptop which only has a single HDD slot,
> often has SD/MMC cardreader slots. If populated with a card for L2ARC,
> can it be expected to boost the laptop''s ZFS performance?
You won''t find that type of card with performance that''s worth
a damn.  Worse yet, it will likely be extremely unreliable.

In a SSD, all the performance and reliability come from intelligence in the
controller, which emulates SATA HDD on one side, and manages Flash memory on the
other side.  Things like wear leveling, block mapping, garbage collection, etc,
that''s where all the performance comes from.  You''re not going
to get it in a USB stick or a SD card.  You''re only going to get it in
full size SSD''s that consume power, and to some extent, the good stuff
will cost more.  (But of course, there''s no way for the consumer to
distinguish between paying for quality, and paying for marketing and margin,
without trying it.)

Even if you do try it, most likely you won''t know the difference until
a month later, having two identical systems with identical workload
side-by-side.  This is NOT to say the difference is insignificant; it''s
very significant, but without a point of reference, you don''t have any
comparison.  All the published performance specs are fudged - but not lies -
they represent optimal conditions, which are unrealistic. All the mfgrs are
going to publish comparable specs, and none of them represent real life usage.