The fix is specific to our samba branch and how we use samba. I think probably a more generic workaround for samba’s VFS in general may be called for, but there are arguments to be made for not doing what I did. My fix here is admittedly not great. We transition from async writes to sync writes (blocking main loop of client smbd). If storage ends up blocking too long then you may trade OOM with clients disconnecting. This maybe pushes things over the hump where smbd doesn’t go OOM, but it’d be better if (IIRC) proxmox didn’t do this.
Sometimes there are fixes that work for us, but maybe aren’t suitable for all samba installs. For example, we had some issues with queuing and samba’s pthread-based AIO in FreeBSD for core, but once I wrote a VFS module to use FreeBSD’s native kqueue-based async libraries the issue went away. The problem is that to do this I had to write a brand new tevent backend based on kqueue.
I had enough time to debug TrueNAS-based libtevent issues on our custom FreeBSD kernel, but dumping something that large on the samba team without intention to support it for BSD in general would be inappropriate in my mind because libtevent changes impact everything.
So whether in particular I push a changeset upstream depends on multiple factors:
- my free time / memory (sometimes I get busy and forget to file a bug report / make merge request upstream). Even after merge request is made, the particulars of the fix may be deemed by other samba team members to be inappropriate for general public (and that’s okay).
- Whether in my judgment the fix is too narrowly focused on our particular use-case. A lot of open source projects are resource constrained on code review and maintenance.
If TrueNAS fixes the problem for you, then great! Use us. We’re free and don’t put any limitations on you.