/mapfs

Primary LanguageGoApache License 2.0Apache-2.0

mapfs

Go-based FUSE file system for uid mapping local file access designed to be used as part of mapfs-release.

In CloudFoundry NFS volume services, the NFS driver will start mapfs when the uid or gid parameters are specified when binding an NFS mount. MapFS will expose a FUSE filesystem that is mounted into the app container, and the app can read and write from. This is backed by an NFS mount. MapFS replicates file access so that as far as NFS is concerned, the file access is done with the uid and gid specified.

Performance

Because an app can potentially go faster than NFS (which is limited by network bandwidth), it's possible for requests to stack up in MapFS while it waits for NFS to respond. Currently, go-fuse does not implement backpressure or load shedding. For every request in-flight, a buffer and a goroutine will be created, so MapFS can consume high memory and processor when the app accesses the filesystem faster than NFS responds.

Configuration

There is an optional configuration file that can be placed at /var/vcap/jobs/mapfs/config/mapfs.yml that will allow MapFS to be configured. Configuration keys are: - debug - enables go-fuse debug mode. Logs are written to /var/vcap/sys/log/mapfs/mapfs.$$.log where $$ is the process ID. - single_threaded - enables go-fuse single threaded mode. Can reduce memory pressure, and may slow down access. - cpu_profile - writes a Go pprof CPU profile to the specified path. - mem_profile - when the process receives a SIGUSR1 a Go pprof memory profile will be written to the path with a timestamp as a file suffix. - soft_mem_limit - soft memory limit in bytes. Equivalent to setting GOMEMLIMIT environment variable.

The configuration file is read on startup. To restart MapFS just kill -9 the existing process and the NFS Driver will start a new one. This may break running apps.

Running tests

make test

Contributing

See the Contributing.md for more information on how to contribute.

Working Group Charter

This repository is maintained by Service Management under Volume Services area.

Important

Content in this file is managed by the CI task sync-readme and is generated by CI following a convention.