Alexander Motin

> I'm not seeing [ea74cde](https://github.com/openzfs/zfs/commit/ea74cdedda8b9575d7e94198d38f12943ac41343), but was hoping to see it with 2.3.3 after #17340 got merged. > > It had been part of the last staging preparations in #17371...

@behlendorf I suspect "Remove mg_allocators" depends on "Unified allocation throttling". We have them both in our TrueNAS patch set, but see yourself if that is too much for 2.3.

@robn I was several times thinking about limiting minimal block size to either clone or deduplicate, since it might be not really efficient to clone or dedup too small file(s),...

Have you tried to set `zfs_arc_shrinker_limit=0` after updating to the latest 2.2.x release? It was made default in 2.3.0: https://github.com/openzfs/zfs/pull/16909 .

@XyFreak In the `arc_summary.txt` I see that your ARC freed everything else it could at that point, but there appears 36GB that it can not free for some reason (supposedly...

@runderwo ZFS allocates ARC in as big chunks as kernel allows. The more memory is fragmented, the smaller are new allocations, and potentially higher fragmentation is future. ARC memory is...

I am not sure it is really a problem of ZFS, at least not it alone. Each time you stat a new file, there are several structures allocated: dnode, sa,...

@maru-sama The fact that ARC is allowed to use almost all of RAM in 2.3 is not a bug, but feature. Once there appear memory pressure from the kernel and...

@brian-maloney As I see, most of your ARC size is reported as non-evictable metadata, which means something is actively referencing it. It might be metadata blocks backing dnodes, referenced by...

@shodanshok Yes, `zfs_arc_max` should still be honored, I haven't said otherwise. It just changed the default value from 50% to somewhere about 95%.