by raattgift » Thu Mar 28, 2013 7:53 am
One doesn't add an L2ARC for sustained-MB/s-from-the-L2ARC per se; they're for random-IOPS-from-the-L2ARC.
Mostly what you want to have in the L2ARC is warm zfs metadata, POSIX metadata, and small files (hot ones should be in ARC); all of these may be seeked to again at some point, robbing the pool of disk IOPS for very short reads. A solid state L2ARC, even one that is slow at writing and not too fast for reading, is still likely to remove seeks from seek-limited media (disks).
In most cases, disks (especially arrays thereof) will perform sequential reads at least as well as solid state L2ARCs, so therefore the L2ARC design (like the ARC one) tries to maximize the "sequentialness" of storage device activity. The cases where L2ARC has much more bandwidth than the pool it's attached to is easy to come by in Macs (a slice on an internal SSD makes for a fine L2ARC, and its sequential read bandwidth will be much greater than a set of disks attached via a single firewire bus. There is little to be done about that in the current ZEVO version, and in any case splitting a multi-disk pool across multiple external IO buses would be a greater win (writes benefit too).
In your case, the "not for production use" should really apply to USB2 at all. It is and always has been a source of tremendous problems for storage systems, including zfs, across many different OS platforms. ZEVO should outright warn people (via growl, even) when devices are attached via USB2.
(USB3 is OK, except for the occasions where USB3 devices attach as USB2 ones, devastating their performance and reliability).