Re: [LSF/MM TOPIC ATTEND][RFD] ZUFS - Zero-copy User-mode File System

[Boaz Harrosh <boazh@netapp.com>]

On 01/02/18 20:34, Chuck Lever wrote:
<>
> This work was also presented at the SNIA Persistent Memory Summit last week.
> The use case of course is providing a user space platform for the development
> and deployment of memory-based file systems. The value-add of this kind of
> file system is ultra-low latency, which is a challenge for the current most
> popular such framework, FUSE.
> 
> To start, I can think of three areas where specific questions might be
> entertained by LSF/MM attendees:
> 
> - Spectre mitigations make this whole "user space filesystem" arrangement even
> slower, thanks to additional context switches between user space and the kernel.
> What can be done for FUSE and ZUFS to reduce the impact of Spectre mitigations?
> 

Sigh !!

What about a different interface for a "trusted" binary with "Spectre mitigation"
off.
I know Redhat guys have a project where they want to sign and verify by Kernel all
systemd /sbin/* binaries. If these binaries have such an hardened trust could
we make them faster? (ie back to regular speed)

> - The fundamental innovation of ZUFS is porting Solaris "doors" to Linux. A
> "door" is a local RPC mechanism that stays on the same thread to reduce
> scheduling overhead during calls to services provided by daemons on the local
> system. Is there interest in building a generic "doors" facility in Linux?
> 

People said I should look into the Binder project from Google. It is already
in Kernel, and is used by Android. As I understand they have exactly such
an object like you describe above. Combined with my thread-array it sounds
like what I want.

> - ZUFS currently supports only synchronous calls to the file system, as the
> assumption is the services (filesystems) will be I/O-less, typically. Is there
> a need to support asynchronicity in the ZUFS API?
> 

There is a plan for async ops, the Server returns "PENDING" and then the
Operation is completed later by the server on some Async back channel.
With some kind of a cookie system. But I have not come to implement it yet.
This will cost because it will need a double mapping of application pages.
But I assume async means it is slower, and it is still cheaper then copy.
So yes, it is on the roadmap.

In General locks are OK in a sync-operation but any need for re-entering
the Kernel, Say to read from disk, will need to be completed ASYNC and the
zt-channel freed for other operations.

> 
> --
> Chuck Lever
>

Thanks
Boaz