Two ZFS pools on one system: load on one pool badly affects other one

[Lev Serebryakov]

On 21.04.2020 19:39, Zaphod Beeblebrox wrote:
> [ regarding zfs arc cache on two pools, where one pool can clear the cache of the other ]
> 
> ... have you tried introducing an l2 cache on an SSD for the "private" pool?
  I've tried to add L2ARC to torrents pool (as "private" pool is more-or-less sequential read, it contains a lot of photos, for example), and it was mistake: SATA SSD was destroyed in 6 months, and hitrate was about 10% (10% of 7% of ARC misses!).
  I didn't thinks about adding L2ARC for "private" pool as I don't have PCIe lines for NMVe left (it is old E3-1220v3 based system), and SATA SSD is slower than 5 fast HDDs which comprise "private" pool in terms of linear read. I understand, that SSD is much better in terms of latency, of course, but as most real access to "private" pool is linear access to large files, I didn't think tat it could help.

> It seems to me that size of the l2 ARC are pool specific (where the division of memory in the l1 ARC is not).  It doesn't surprise me that this happens.  I have a large RAIZ2 pool for media (currently 40T, expanding to 60T shortly) on an otherwise general home server with 32G RAM.  There is also a mirrored pool (root, home, a few things) on this machine for various reasons (like not booting from such a large raid) and things got overall better when I added a few hundred gig of l2 cache to each of the two pools.

 It doesn't look like cache wash-out, as I tried this "svn up" "test" on cold caches, not over-and-opver again. Looks like it is some lock contention...

 But I'll try to find some SATA SSD and add it as L2ARC for "private" cache (as I said, L2ARC cache for torrents was bad idea!).

-- 
// Lev Serebryakov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20200421/3639b8dc/attachment.sig>