| Message ID | 5395838E.3080505@cn.fujitsu.com |
|---|---|
| State | Rejected |
| Headers | show |
Hi Ditang- On Jun 9, 2014, at 5:51 AM, Ditang Chen <chendt.fnst@cn.fujitsu.com> wrote: > I tested in Fedora20, when junction type is nfs-fedfs, the nfsref > cannot resolve FSN if the export path is "/". > > # nfsref -d --type=nfs-fedfs add /.domainroot/example.net/s2 server2.example.net / > ... > nfsref: nsdb_normalize_path: result = '/' > nfsref: nsdb_count_components: length = 4, count = 0, path = '/' > nfsref: nsdb_alloc_zero_component_pathname: Zero-component pathname > nfsref: nsdb_construct_nfsuri: NFS URI: nfs://Server2.example.net/ Just so I understand what is going on here: According to section 2.8.1.2 of http://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-protocol/ Therefore, a double slash always follows the authority component of an NFS URI. For example, the NFSv4 pathname "/" is represented by two slash ("/") characters following an NFS URI's authority component. It looks like nsdb_construct_nfsuri() is building an incorrect NFS URI in the case where just “/“ is the input pathname. The URI should have a second slash on the end, correct? nfsref then adds this incorrect URI to the NSDB. > ... > > # nfsref -d lookup s2/ > .. > nfsref: nsdb_parse_nfs_uri: parsing 'nfs://server2.example.net/' > nfsref: nsdb_uri_pathname_to_path_array: NFS URI has short pathname component > nfsref: nsdb_resolve_fsn_parse_entry: parsing failed: FEDFS_ERR_BADNAME > nfsref: nfsref_lookup_resolve_fsn: Failed to resolve FSN 5f4bace9-14b3-4626-8d39-4b0624c18a22: FEDFS_ERR_ACCESS > ... > > Signed-off-by: chendt.fnst@cn.fujitsu.com > --- > src/libnsdb/path.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/libnsdb/path.c b/src/libnsdb/path.c > index c58dc89..e269afc 100644 > --- a/src/libnsdb/path.c > +++ b/src/libnsdb/path.c > @@ -630,7 +630,7 @@ nsdb_path_array_to_uri_pathname(char * const *path_array, UriUriA *uri) > char *component; > unsigned int i; > > - pos = nsdb_new_uri_path_segment(""); > + pos = nsdb_new_uri_path_segment("/“); An empty URI path segment is supposed to give us just a URI path separator. I wonder why uriToStringA() is not converting that initial empty path segment to an extra URI path segment separator. > if (pos == NULL) > return FEDFS_ERR_SVRFAULT; > result = pos; > -- > 1.8.4.2 > -- Chuck Lever chuck[dot]lever[at]oracle[dot]com
On Jun 9, 2014, at 11:34 AM, Chuck Lever <chuck.lever@oracle.com> wrote: > Hi Ditang- > > On Jun 9, 2014, at 5:51 AM, Ditang Chen <chendt.fnst@cn.fujitsu.com> wrote: > >> I tested in Fedora20, when junction type is nfs-fedfs, the nfsref >> cannot resolve FSN if the export path is "/". >> >> # nfsref -d --type=nfs-fedfs add /.domainroot/example.net/s2 server2.example.net / >> ... >> nfsref: nsdb_normalize_path: result = '/' >> nfsref: nsdb_count_components: length = 4, count = 0, path = '/' >> nfsref: nsdb_alloc_zero_component_pathname: Zero-component pathname >> nfsref: nsdb_construct_nfsuri: NFS URI: nfs://Server2.example.net/ > > Just so I understand what is going on here: > > According to section 2.8.1.2 of > > http://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-protocol/ > > Therefore, a double slash always follows the authority component of > an NFS URI. For example, the NFSv4 pathname "/" is represented by > two slash ("/") characters following an NFS URI's authority > component. > > It looks like nsdb_construct_nfsuri() is building an incorrect NFS URI in > the case where just “/“ is the input pathname. The URI should have a second > slash on the end, correct? > > nfsref then adds this incorrect URI to the NSDB. I confirmed that the issue exists only when specifying a pathname of “/“. I’m using locally built fedfs-utils 0.10.2+ on Fedora 19. I created two FSNs with the nsdb-create-fsl command. I specified a pathname of “/“ for the first, and “/share/home” for the second. The fedfsNfsURI attribute for the first record is missing the double-slash, and attempting to resolve that FSN using the nsdb-resolve-fsn command results in FEDFS_ERR_BADNAME. [cel@seurat nsdbc]$ ldapsearch -h nsdb.1015granger.net -x -b ou=fedfs,dc=1015granger,dc=net -s subtree objectclass=fedfsFsl # extended LDIF # # LDAPv3 # base <ou=fedfs,dc=1015granger,dc=net> with scope subtree # filter: objectclass=fedfsFsl # requesting: ALL # # 0543d9f1-8427-417e-95ec-2b067a612403, 45bf7779-51f3-442e-8dac-b8e48315eb93, fedfs, 1015granger.net dn: fedfsFslUuid=0543d9f1-8427-417e-95ec-2b067a612403,fedfsFsnUuid=45bf7779-51 f3-442e-8dac-b8e48315eb93,ou=fedfs,dc=1015granger,dc=net objectClass: fedfsFsl objectClass: fedfsNfsFsl fedfsFslUuid: 0543d9f1-8427-417e-95ec-2b067a612403 fedfsFsnUuid: 45bf7779-51f3-442e-8dac-b8e48315eb93 fedfsNfsURI: nfs://bazille.1015granger.net/ fedfsNfsCurrency: -1 fedfsNfsGenFlagWritable: FALSE fedfsNfsGenFlagGoing: FALSE fedfsNfsGenFlagSplit: TRUE fedfsNfsTransFlagRdma: TRUE fedfsNfsClassSimul: 0 fedfsNfsClassHandle: 0 fedfsNfsClassFileid: 0 fedfsNfsClassWritever: 0 fedfsNfsClassChange: 0 fedfsNfsClassReaddir: 0 fedfsNfsReadRank: 0 fedfsNfsReadOrder: 0 fedfsNfsWriteRank: 0 fedfsNfsWriteOrder: 0 fedfsNfsVarSub: FALSE fedfsNfsValidFor: 0 # c6cd3166-4c83-482a-af6c-f6e4fb4b1db5, 45bf7779-51f3-442e-8dac-b8e48315eb93, fedfs, 1015granger.net dn: fedfsFslUuid=c6cd3166-4c83-482a-af6c-f6e4fb4b1db5,fedfsFsnUuid=45bf7779-51 f3-442e-8dac-b8e48315eb93,ou=fedfs,dc=1015granger,dc=net objectClass: fedfsFsl objectClass: fedfsNfsFsl fedfsFslUuid: c6cd3166-4c83-482a-af6c-f6e4fb4b1db5 fedfsFsnUuid: 45bf7779-51f3-442e-8dac-b8e48315eb93 fedfsNfsURI: nfs://bazille.1015granger.net//share/home fedfsNfsCurrency: -1 fedfsNfsGenFlagWritable: FALSE fedfsNfsGenFlagGoing: FALSE fedfsNfsGenFlagSplit: TRUE fedfsNfsTransFlagRdma: TRUE fedfsNfsClassSimul: 0 fedfsNfsClassHandle: 0 fedfsNfsClassFileid: 0 fedfsNfsClassWritever: 0 fedfsNfsClassChange: 0 fedfsNfsClassReaddir: 0 fedfsNfsReadRank: 0 fedfsNfsReadOrder: 0 fedfsNfsWriteRank: 0 fedfsNfsWriteOrder: 0 fedfsNfsVarSub: FALSE fedfsNfsValidFor: 0 # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 [cel@seurat nsdbc]$ -- Chuck Lever chuck[dot]lever[at]oracle[dot]com
diff --git a/src/libnsdb/path.c b/src/libnsdb/path.c index c58dc89..e269afc 100644 --- a/src/libnsdb/path.c +++ b/src/libnsdb/path.c @@ -630,7 +630,7 @@ nsdb_path_array_to_uri_pathname(char * const *path_array, UriUriA *uri) char *component; unsigned int i; - pos = nsdb_new_uri_path_segment(""); + pos = nsdb_new_uri_path_segment("/"); if (pos == NULL) return FEDFS_ERR_SVRFAULT; result = pos;
I tested in Fedora20, when junction type is nfs-fedfs, the nfsref cannot resolve FSN if the export path is "/". # nfsref -d --type=nfs-fedfs add /.domainroot/example.net/s2 server2.example.net / ... nfsref: nsdb_normalize_path: result = '/' nfsref: nsdb_count_components: length = 4, count = 0, path = '/' nfsref: nsdb_alloc_zero_component_pathname: Zero-component pathname nfsref: nsdb_construct_nfsuri: NFS URI: nfs://Server2.example.net/ ... # nfsref -d lookup s2/ .. nfsref: nsdb_parse_nfs_uri: parsing 'nfs://server2.example.net/' nfsref: nsdb_uri_pathname_to_path_array: NFS URI has short pathname component nfsref: nsdb_resolve_fsn_parse_entry: parsing failed: FEDFS_ERR_BADNAME nfsref: nfsref_lookup_resolve_fsn: Failed to resolve FSN 5f4bace9-14b3-4626-8d39-4b0624c18a22: FEDFS_ERR_ACCESS ... Signed-off-by: chendt.fnst@cn.fujitsu.com --- src/libnsdb/path.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)