Stakeholders

Lei Huang, Mohamad Chaarawi, Ashley Pittman

Introduction

...

Applications normally need to be modified by adopting the DFS API to fully take advantage of the performance provided by DAOS. Such requirements need extra effort from software developers for porting and maintaining. For applications that do not support DFS, dfuse is used to support applications using POSIX interface without the need of code changes with degraded I/O performance compared using native DFS API. Interception library libioil.so was introduced to boost read/write bandwidth by bypassing dfuse for read()/write() and their variants. Metadata related functions (e.g., open, stat, unlink, etc.) still suffer from inferior performance restricted by dfuse. A new interception library that intercepts all I/O related functions in glibc (including read/write as well as metadata related functions) is required to deliver good performance using POSIX comparable with using DFS.

...

Current code was developed and tested on x86_64. We do have ongoing work to port the library to Arm64, but we have not tested on Arm64 yet.

dfuse has to be mounted for pool & container handle resolution and to handle some operations on the container that we do not supported yet.

• Support for multiple pool and containers within a singled dfuse mountpoint is not there yet (each container accessed should be mounted separately), i.e. no UNS support (concerns about the overhead of getfattr())multi user access is supported as long as permissions of pool and container are set properly

• Large overhead for small tasks (200~300 ms in daos_init())

• Not working for statically linked executable (such as Go applications)

• No support of creating a process with the executable and shared object files stored on DAOS yet

• No support for applications using fork yet (ibverbs not working due to verbs limitation. Tcp seems not working either.)

...