On Jun 9, 2014, at 11:34 AM, Chuck Lever <[email protected]> wrote:
> Hi Ditang- > > On Jun 9, 2014, at 5:51 AM, Ditang Chen <[email protected]> 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 _______________________________________________ fedfs-utils-devel mailing list [email protected] https://oss.oracle.com/mailman/listinfo/fedfs-utils-devel
