We'd like to be able to export user's data via NFS.


  • Yehuda (Red Hat)

Interested Parties

  • Name (affiliation)

Current Status

Detailed Description

Access to rgw objects through nfs. Use case is users that need to migrate existing data into rgw. The mount will be done on a single user’s data. There are two options:
The nfs mount will be done on the user itself. The nfs mount will present a view of the user’s buckets at the top level, the next level will present the bucket view
The mount will be done on a single user’s bucket.

Listing directory
Bucket data will be shown using the virtual directory structure. For example, having a key /foo/bar, the correct directory structure will be represented, and when listing the root directory, the server will return the ‘foo’ directory.
Creating directory
an empty object that contains the name of the directory will be created
Removing directory
if directory is ‘empty’, remove the object associated with the directory. This is racy, we might not want to support it
Open file
Verify validity of corresponding object
Read opened file
Read corresponding object
Write file
Chunked write, continue writing from previous offset, no seeks.
Translate user / group permissions to ACLs

Implementation Options
ganesha (fuse FSAL) -> s3fs-fuse
s3fs mounts S3 buckets (works at the bucket level). Some work will be needed to make it work on the user level (if needed). It supports most of the functionality out of the box. Doesn’t translate permissions to ACLs, but keeps that data as application specific attributes on the objects.
ganesha dropped support for the fuse FSAL recently due to heavy development that was done for version 2.0, and made it obsolete. Some work will be needed to resurrect the fuse FSAL, not clear how hard that would be, however, it seems that there is/was demand for it to happen.
any nfs server -> s3fs-fuse
more moving parts than (1), s3fs-fuse still has the same issues.
ganesha (librgw FSAL) -> librgw[fs]
requires developing both librgw, and librgw FSAL layer for ganesha. Note that librgw is not likely to go through the radosgw authentication / authorization sequence, so permissions might be problematic. Also will require setting cephx user on the ceph cluster, and not using the user’s S3 credentials.

Work items

Coding tasks

  1. Task 1
  2. Task 2
  3. Task 3

Build / release tasks

  1. Task 1
  2. Task 2
  3. Task 3

Documentation tasks

  1. Task 1
  2. Task 2
  3. Task 3

Deprecation tasks

  1. Task 1
  2. Task 2
  3. Task 3