Jeff Layton has uploaded this change for review.
FSAL: reach into op_ctx->ctx_export to get fs_root for fs_locations
Currently, the FSAL populates a field in the fs_locations structure,
but that seems cumbersome and somewhat of a layering violation.
The op_ctx should have a record of the export, so we can just reach
into there and grab the pseudoroot.
While we're at it, fix the case where we don't have fs_locations
structure. RFC5661 says:
When the fs_locations attribute is interrogated and there are no
alternate file system locations, the server SHOULD return a zero-
length array of fs_location4 structures, together with a valid
fs_root.
Now that we get fs_root from the export, we can handle this case.
This allows us to remove a large chunk of pretty nasty code in
FSAL_VFS, which tried to replace components of the pathname with
the pseudoroot.
None of that is necessary. fs_locations is about the export, not a
particular path in it. We tell the client what the root of the export
is locally, and the root of the export on the other servers, and it
handles the rest of the path inside the export.
Change-Id: I667b1e37eefe09c4bbbe6784db2f98c19b209ec1
Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
M src/FSAL/FSAL_GPFS/handle.c
M src/FSAL/FSAL_VFS/subfsal_helpers.c
M src/Protocols/NFS/nfs_proto_tools.c
M src/include/fsal_types.h
M src/include/nfs4_fs_locations.h
M src/support/nfs4_fs_locations.c
6 files changed, 17 insertions(+), 91 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/10/422010/1
To view, visit change 422010. To unsubscribe, or for help writing mail filters, visit settings.