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
--
Dr.-Ing. Norman Feske
Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
_______________________________________________
users mailing list -- users@lists.genode.org
To unsubscribe send an email to users-le...@lists.genode.org
Archived at
https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/message/DKWN5NNXBICPKU44XNVGJBA2KPNQRZRT/
