Point taken. In retrospect, directfs is not a good name as it gives the impression of a new filesystem implemention. I should have named this more along the lines of "direct access mode" as some of you have pointed out.
> The old model howevwr was that read and write were translated to rpc calls to the broker.
In the old model, reads/writes were not translated to RPCs. Only for regular files, the broker was donating FDs to the sentry (userspace kernel) and the sentry was allowed to perform read(2)/write(2) directly. This was done as a performance optimization long back.
What is different with directfs is that now the broker additionally donates FDs for other types of files as well (directories, sockets, etc) and the sandbox is allowed to operate on those FDs with more syscalls like mkdirat, symlinkat, etc. This drastically increases the independence of the sandbox is performing filesystem operations, so it does not need to invoke the broker via RPCs.
As described, the sentry is still constrained to operating on only the container filesystem via namespaces and other Linux security primitives.
gVisor recently rolled out a filesystem optimization which substantially improves filesystem performance for sandboxed workloads. It involves setting up a overlayfs mount for the container root filesystem in gVisor's user-space kernel. This blog has more details about how this optimization works and how much performance boost can be seen by certain workloads.
Point taken. In retrospect, directfs is not a good name as it gives the impression of a new filesystem implemention. I should have named this more along the lines of "direct access mode" as some of you have pointed out.
Thanks for the feedback.