L2ARC write throttling algorithm was created many years ago and does not work well in modern days. It is very bursty and often not reaching the target speed expectations. Simple attempts to tune module parameters recommended by many to make it faster may not provide expected results or have side effects, so some algorithm changes are needed.

• Introduction of ARC multilists made L2ARC writing (handling one sublist at a time) quite random, depending on whether it find something to write in a sublist it decided to look on. Instead it should be able to look on multiple sublists within one burst, preferably up to even depth.

• Each time L2ARC scans the ARC eviction lists it does it from the tail. The depth of scanning is limited by headroom coefficient to not waste CPU too much if there is nothing to write. Since ARC eviction lists are only filled from heads, we could save our positions between iterations to not waste CPU time. That way it might be difficult to write only blocks that are going to be evicted from ARC “soon”, since we don’t know what was evicted after our saved position, but may be it is less important if we have predictable and stable write rate, or may be we could still do scans from the tail from time to time, or we could think of something else, like accounting and limiting fraction of ARC that .

• L2ARC write speed should be stable over longer periods of time. Bursty write workloads may evict too much data from ARC that will not be written to L2ARC. Partially it is limited by very conservative headroom setting mentioned above. But just few minutes later after the burst end L2ARC will stop its writing, again not reaching the target write speed expecatations.

• L2ARC has a boost mechanism to accelerate writing after system boot up to the point of ARC warmup. It was designed to faster warm up L2ARC if is it empty. But it was designed before persistent L2ARC was implemented. Instead I think we should use boot rates if L2ARC usage is below certain threshold, unrelated to ARC warmup. The fact that ARC is cold does not mean we should write L2ARC faster if it is full. And back, the fact that ARC is warm does not mean we should slow down L2ARC write if it is empty.

• We need to think again about what data do we write into L2ARC (data vs metadata, prefetch vs demand, etc). IIRC there was a parameter that bypass L2ARC reading in certain cases (prefetch?). But from the L2ARC device wear it would be better to optimize what we write than what we read. May be we could think of some self-tuning.