Hi Stefan,
One of our vfs plugins needs a bit more RAM per client. Therefore the question came up, if RAM quota donation from the client is supported for vfs plugins and if so where one might find an example of this mechanism.
There is no existing off-the-shelf solution for this use case.
At the VFS-library level, there exists no notion of a session client. So the feature cannot be implemented locally within the VFS. It would call for an alternative file-system server implementation. But even if considering that, there are open questions with no obvious answers.
1. The file-system session interface has no means to use dynamic session quota as budget for storing payload. The session quota is solely used for setting up the communication (allocation of the shared I/O buffer and session object).
2. There is no mechanism to propagate the need for session upgrades as response to a write operation. Write operations are asynchronous. The handling of such responses would impose synchronous mode of operation into the interface, which is generally not desirable.
3. What should happen with the data once the writer closes its file- system session? The backing store vanishes after all. The logical answer would be to remove the data (as implemented by report_rom when the report client leaves). However, for a file system server, this behavior would be quite surprising when thinking of a typical short-running program that exits after producing some output. So the practical use case for such policy seems quite narrow.
Your question reminds me of [1].
[1] https://github.com/genodelabs/genode/issues/3712
Can your problem potentially be solved at a different level of abstraction? E.g., should the RAM VFS-plugin support a total write limit per <ram> instance, one could configure a VFS server like so:
<vfs> <ram/> <dir name="limited"> <ram limit="10M"/> </dir> </vfs> <policy label="greedy" root="/limited/" /> <policy label="inspect" root="/" />
This would restrict a "greedy" client to the bounds of the /limited/ RAM file system whereas the "inspect" client is not restricted.
That said, such an upper bound of the RAM VFS plugin is currently not implemented. The issue linked above is still open.
Cheers Norman