diff --git a/src/client/dfs/README.md b/src/client/dfs/README.md
index 37cf9457c60..a5a28e7436a 100644
--- a/src/client/dfs/README.md
+++ b/src/client/dfs/README.md
@@ -162,20 +162,10 @@ directory containing the actual value of the symlink.
 ## Access Permissions
 
 All DFS objects (files, directories, and symlinks) inherit the access
-permissions of the DFS pool that they are created with. So when a user is trying
-to access an object in the DFS namespace, their real/effective uid/gid are
-compared against those of the pool's uid and gid, which are obtained when
-connecting to the pool. The check then is done with the stored object mode and
-depending on the type of access being requested (R, W, X) and the object mode,
-access permission is determined. In the source code, this is implemented in the
-function `check_access()`.
+permissions of the DFS container that they are created with. So the permission
+checks are done on dfs_mount(). If that succeeds and the user has access to the
+container, then they will be able to access all objects in the DFS
+namespace.
 
 setuid(), setgid() programs, supplementary groups, ACLs are not supported in the
 DFS namespace.
-
-## DFUSE_HL
-
-A simple high level fuse plugin (dfuse_hl) is implemented to use the DFS API
-and functionality with existing POSIX tests and benchmarks (IOR, mdtest,
-etc.). The DFS high level fuse exposes one mounpoint as a single DFS namespace
-with a single pool and container.
diff --git a/src/object/README.md b/src/object/README.md
index a4c199cedf4..bfedbc8bc78 100644
--- a/src/object/README.md
+++ b/src/object/README.md
@@ -58,7 +58,8 @@ bandwidth by allowing concurrent reads from different replicas.
 #### Client-side Replication
 
 Client replication is the mode that it is synchronous and fully in the client
-stack, to provide high concurrency and low latency I/O for the upper layer.
+stack, to provide high concurrency and low latency I/O for the upper layer. This
+mode is not default and is only provided for testing purposes.
 -   I/O requests against replicas are directly issued via DAOS client; there is
     no sequential guarantee on writes in the same epoch, and concurrent writes
     for a same object can arrive at different replicas in an arbitrary order.