Alexander Motin

> Does that mean that the 50 % RAM limit for ARC that was in place for ZFS 2.2 and before does not apply anymore? Right. > Where can I...

@ahesford "but we all know" is not an argument. We discussed it with many developers multiple times, and nobody could give good arguments why it should not work. But since...

Do I need to repeat again that it is not a `zfs_arc_max` problem? Something holds those ARC buffers from eviction. There are parallel issue(s) about prune code integration with different...

> * `zfs_arc_max` will not honor the 1/2 of system memory rule for Linux It is just not a rule, it was a dirty hack to make it live somehow,...

In case there are suspicions that it might be related to block cloning, please try this: https://github.com/openzfs/zfs/pull/17431 .

@AceSlash With `zfs_arc_dnode_limit_percent=95` you've allowed dnodes to consume 95% of maximum arc size at the time, and then you are complaining that dnodes consumed all your ARC, squashing everything else...

> > I decoded the references from offsets to line numbers, counts are for 60 second window: > > `txg_wait_synced(dmu_objset_pool(rwa->os), 0);` > > Looking at [#17434](https://github.com/openzfs/zfs/pull/17434) do you think a...

The cause of this issue is that each fsync() request on a file concatenates all the async write data of that file that are not yet written to a stable...

@RubenKelevra You've lost me pretty quick. ;) > I think the solution would be to reconsider the way we handle queuing for processes that send too much requests. Traditionally, requests...

> So instead of accepting say 1 GB to write, because we got 1 GB of space in memory assigned for a write buffer and then struggling to write it...