[fedfs-utils] [PATCH fedfs-utils] libnsdb: Cannot resolve FSN if the pathname is "/"

[Chuck Lever]

On Jun 9, 2014, at 11:34 AM, Chuck Lever <chuck.lever at oracle.com> wrote:

> Hi Ditang-
> 
> On Jun 9, 2014, at 5:51 AM, Ditang Chen <chendt.fnst at 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 at 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 at seurat nsdbc]$


--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com