Bug 1128820
| Summary: | Unable to ls -l NFS mount from OSX 10.9 client on pool created with stripe | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Eric Horwitz <E3GH75> | ||||||||
| Component: | nfs | Assignee: | Harshavardhana <fharshav> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||||||
| Severity: | urgent | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 3.5.2 | CC: | cww, E3GH75, jclift, ndevos | ||||||||
| Target Milestone: | --- | Keywords: | Triaged | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2014-09-09 07:26:31 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Eric Horwitz
2014-08-11 15:23:41 UTC
Is this possible to reproduce from 'master' branch? while using FUSE on OSX? - there has been know problems with Mac NFS client I also verified NFS does not work on version 3.3.2-2 of gluster. I have not tested FUSE on OSX. Is there a pre built version of gluster for OSX? (In reply to E3GH75 from comment #3) > I have not tested FUSE on OSX. > > Is there a pre built version of gluster for OSX? There isn't one, we are planning to support OSX for GlusterFS 3.6 release - and currently 'master' branch has all the fixes necessary to get it running. okay so I should build gluster from 'master' on github for the servers and then attempt NFS test again? Yep, that's worth trying. As a note, GitHub only has a mirror of the GlusterFS source code. It sometimes gets a bit behind, but (just checked) it's fine at the moment, so you're good to use that. :) built and installed 3.7dev NFS no longer works... [2014-08-11 17:21:38.621760] E [nfs3.c:840:nfs3_getattr] 0-nfs-nfsv3: Bad Handle [2014-08-11 17:21:38.621801] W [nfs3-helpers.c:3401:nfs3_log_common_res] 0-nfs-nfsv3: XID: 8bf55f4f, GETATTR: NFS: 10001(Illegal NFS file handle), POSIX: 14(Bad address) [2014-08-11 17:21:38.621878] E [nfs3.c:301:__nfs3_get_volume_id] (-->/usr/lib64/glusterfs/3.7dev/xlator/nfs/server.so(nfs3_getattr+0x1d4) [0x7fb6bd730654] (-->/usr/lib64/glusterfs/3.7dev/xlator/nfs/server.so(nfs3_getattr_reply+0x29) [0x7fb6bd7266a9] (-->/usr/lib64/glusterfs/3.7dev/xlator/nfs/server.so(nfs3_request_xlator_deviceid+0x78) [0x7fb6bd7251e8]))) 0-nfs-nfsv3: invalid argument: xl Sorry yeah, I misread what you meant. :( Would you be able to test: * Compile gluster from master for the servers, and * Compile gluster from master for the OSX clients In theory (!) this should let you do FUSE mounts instead of NFS. Once all of the bugs are ironed out, this should be both more reliable and have better performance. (NFS on OSX has a bad rep, and not just with Gluster ;>) unfortunately I am not familiar with how to build this on OSX.... Same general approach as on Linux. $ git clone <url> $ ./autogen.sh $ configure $ make $ sudo make install That being said, if it goes wrong then the make install can leave bits in wrong places. As an easier thought, are you already familiar with OSX Homebrew? I've been working on a Homebrew formula for OSX for this. If that would be helpful, I can knock it into shape quickly and share it. ? This is an initial Homebrew formula for OSX: https://github.com/justinclift/homebrew/commit/0a6af80642bd0ea3580be2fff94206b650d65269 Or you can grab it directly from here: https://github.com/justinclift/homebrew/raw/0a6af80642bd0ea3580be2fff94206b650d65269/Library/Formula/glusterfs.rb To use it, drop it into your Homebrew formula directory. Generally that's /usr/local/Library/Formula, then run: $ brew install glusterfs --HEAD The --HEAD option is important atm, as that tells Homebrew to grab the latest code from git master branch. :) Does this seem helpful? configure: error: cmockery2 library is required to build glusterfs Any thoughts? Arrrgh. I'd forgotten about that. I need to get the cmockery2 Homebrew formula done first. I'll jump on that now. Um... you might need to wait until tomorrow. :( well is there source I can compile from or have I let the goose out of the cage? Heh Heh Heh, the cmockery2 source is here: https://github.com/lpabon/cmockery2 I'm not that familiar with it (yet), but Luis (the main author) is fairly responsive if you hit issues. :) got it to build! :-) Building gluster failed...
xdr-generic.c:27:29: error: too few arguments to function call, expected 3, have 2
if (!proc (&xdr, res)) {
~~~~ ^
xdr-generic.c:51:30: error: too few arguments to function call, expected 3, have 2
if (!proc (&xdr, args)) {
~~~~ ^
xdr-generic.c:75:30: error: too few arguments to function call, expected 3, have 2
if (!proc (&xdr, args)) {
~~~~ ^
3 errors generated.
make[4]: *** [libgfxdr_la-xdr-generic.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Harsha, any ideas? :) + Justin (In reply to Justin Clift from comment #18) > Harsha, any ideas? :) > Yes in OSX 'proc()' doesn't take variable arguments as in BSD* or Linux. Also this should be just a warning? are you compiling this with "-Werror" ? no I will try that but where in the command list to I add that flag? I tried export CFLAGS="-Werror" but it still errors out when I run make /Applications/Xcode.app/Contents/Developer/usr/bin/make --no-print-directory --quiet all-recursive
Making all in ./contrib/argp-standalone
Making all in .
Making all in libglusterfs
Making all in src
Making all in rpc
Making all in xdr
Making all in src
CC libgfxdr_la-xdr-generic.lo
xdr-generic.c:27:29: error: too few arguments to function call, expected 3, have 2
if (!proc (&xdr, res)) {
~~~~ ^
xdr-generic.c:51:30: error: too few arguments to function call, expected 3, have 2
if (!proc (&xdr, args)) {
~~~~ ^
xdr-generic.c:75:30: error: too few arguments to function call, expected 3, have 2
if (!proc (&xdr, args)) {
~~~~ ^
3 errors generated.
make[4]: *** [libgfxdr_la-xdr-generic.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
I think Harsha was saying that using -Werror will cause the compile to fail, and you should try to avoid it. It sounds like your compiler setting might be pulling it in automatically (thus the failure), and maybe try to stop it doing that? :) > xdr-generic.c:27:29: error: too few arguments to function call, expected 3, > have 2 > if (!proc (&xdr, res)) { > ~~~~ ^ > xdr-generic.c:51:30: error: too few arguments to function call, expected 3, > have 2 > if (!proc (&xdr, args)) { > ~~~~ ^ > xdr-generic.c:75:30: error: too few arguments to function call, expected 3, > have 2 > if (!proc (&xdr, args)) { > ~~~~ ^ > 3 errors generated. > make[4]: *** [libgfxdr_la-xdr-generic.lo] Error 1 > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 Okay - i think the problem doesn't occur on 10.8.5 version - it occurs on 10.9 > - RPC code is changed and made stricter. It was fixed before, but due to some other porting efforts it was reverted for NetBSD by manu - ~~~~commit 618d465295df02ae6d53be1327947a210bb8b47d Author: Emmanuel Dreyfus <manu> Date: Fri May 16 16:58:20 2014 +0200 NetBSD build fixes - Shell scripts: == is specific to bash and ksh. Use = instead. - Shell scripts: use sh instead of bash if bash functionnality is not used - Shell scripts: ${var/search/replace} is specific to bash - sed: The -i option is specific to GNU sed. - Makefiles: $< outside of generic rules only work in GNU make. - xdrproc_t() is not universally defined as variadic. Do not specify third argument if it is not used - NetBSD FUSE specific: only include <perfuse.h> in FUSE client code, it harms in other locations - configure: Search for gettext() in libintl as NetBSD stores it there - Like MacOS X, NetBSD has unmount(2) and not umount(2) (un vs u) Some other build issues previously included in this change were removed: - __THROW macro, addressed in http://review.gluster.com/#/c/7757/ - getmntent() compat shared with MacOS X, in http://review.gluster.com/#/c/7722/ This patchset adds warning fixes for mount_glusterfs BUG: 764655 Change-Id: I2f1faf8ff96362d3e2baf237b943df619011f1f4 Signed-off-by: Emmanuel Dreyfus <manu> Reviewed-on: http://review.gluster.org/7783 Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Harshavardhana <harsha> ~~~~ Especially this change - xdrproc_t() is not universally defined as variadic. Do not specify third argument if it is not used On OSX 10.8.5 ~~~~~~~~~~~ /* * A xdrproc_t exists for each data type which is to be encoded or decoded. * * The second argument to the xdrproc_t is a pointer to an opaque pointer. * The opaque pointer generally points to a structure of the data type * to be decoded. If this pointer is 0, then the type routines should * allocate dynamic storage of the appropriate size and return it. */ #ifdef _KERNEL typedef bool_t (*xdrproc_t)(XDR *, void *, unsigned int); #else /* * XXX can't actually prototype it, because some take three args!!! */ typedef bool_t (*xdrproc_t)(XDR *, ...); #endif ~~~~~~~~~~~ On Linux ~~~~~~~~~~~ /* * A xdrproc_t exists for each data type which is to be encoded or decoded. * * The second argument to the xdrproc_t is a pointer to an opaque pointer. * The opaque pointer generally points to a structure of the data type * to be decoded. If this pointer is 0, then the type routines should * allocate dynamic storage of the appropriate size and return it. * bool_t (*xdrproc_t)(XDR *, caddr_t *); */ typedef bool_t (*xdrproc_t) (XDR *, void *,...); ~~~~~~~~~~~~ On OSX 10.9.4 ~~~~~~~~~~~~ /* * A xdrproc_t exists for each data type which is to be encoded or decoded. * * The second argument to the xdrproc_t is a pointer to an opaque pointer. * The opaque pointer generally points to a structure of the data type * to be decoded. If this pointer is 0, then the type routines should * allocate dynamic storage of the appropriate size and return it. * * * IMPORTANT NOTE: Apple iOS and OS X * * Previous versions of this header file defined the xdrproc_t prototype as * typedef bool_t (*xdrproc_t)(XDR *, ...); * * This prototype is incorrect. One may not use a varargs function pointer * in place of pointer to a function with positional parameters. * This mistake has been masked by the fact that clients of this API would * generally cast their xdr functions as (xdrproc_t), and thus silence compiler * warnings. The code worked because the ABI for varargs routines that pass a * small number of arguments has been the same as the ABI for routines with a * few positional parameters. However, if the ABI differs this will cause the * compiled code to fail. * * Historically, some client xdr routines expected three parameters. This * does not seem to be the case in more recent code, but we have decided to * retain this definition in the XDR library in case some legacy code still * expects three parameters. The library will pass zero as the third * parameter. Routines that expect two parameters will work correctly. * * If your client-side xdr routine is of the form: * bool_t xdr_my_datatype(XDR *, void *); * and you pass your function pointer to routines like xdr_pointer or * xdr_reference using "(xdrproc_t)xdr_my_datatype", then your code will * compile and run correctly. If your code invokes an xdrproc_t callback, * it must be modified to pass a third parameter, which may simply be zero. */ typedef bool_t (*xdrproc_t)(XDR *, void *, unsigned int); ~~~~~~~~~~~~~ A terrible mistake by OSX folks! REVIEW: http://review.gluster.org/8458 (porting: OSX/Darwin 10.9 porting issues) posted (#1) for review on master by Harshavardhana (harsha) REVIEW: http://review.gluster.org/8458 (porting: OSX/Darwin 10.9 porting issues) posted (#2) for review on master by Harshavardhana (harsha) REVIEW: http://review.gluster.org/8458 (porting: OSX/Darwin 10.9 porting issues) posted (#3) for review on master by Harshavardhana (harsha) REVIEW: http://review.gluster.org/8458 (porting: OSX/Darwin 10.9 porting issues) posted (#4) for review on master by Harshavardhana (harsha) REVIEW: http://review.gluster.org/8458 (porting: OSX/Darwin 10.9 porting issues) posted (#5) for review on master by Harshavardhana (harsha) I appreciate all the hard work you guys are doing to fix the Fuze mount for native osx support but what can be done to fix the nfs issues. The compiled version I made yesterday totally broke all nfs support. I can no longer access the volume from my linux systems. It's complaining that the rpcbind doesn't match and the transport layer is not supported. I can post logs as soon as get to the office. It looks like whatever change apple made to nfs in mavericks 10.9 really goofed stuff up. I don't have any 10.8 machines but does nfs work from those clients? Again thanks for all your help. COMMIT: http://review.gluster.org/8458 committed in master by Harshavardhana (harsha) ------ commit fd6765b4a3f8162bf36054cf3de6e88a6bdfadd3 Author: Harshavardhana <harsha> Date: Mon Aug 11 17:36:12 2014 -0700 porting: OSX/Darwin 10.9 porting issues xdrproc_t() arguments are variadic and non-variadic On OSX > 10.9 ------------- typedef bool_t (*xdrproc_t)(XDR *, void *, unsigned int); On OSX < 10.9 ------------ typedef bool_t (*xdrproc_t)(XDR *, ...); FreeBSD all versions ------------ typedef bool_t (*xdrproc_t)(XDR *, ...); NetBSD 6.1.4 ----------- typedef bool_t (*xdrproc_t)(XDR *, const void *); Linux all versions ----------- typedef bool_t (*xdrproc_t)(XDR *, void *,...); This weird and odd implementations across various platforms should be handled properly. Change-Id: Iad8b7da2e5b82526bf3708cff31ab10ce09f59c9 BUG: 1128820 Signed-off-by: Harshavardhana <harsha> Reviewed-on: http://review.gluster.org/8458 Reviewed-by: Emmanuel Dreyfus <manu> Tested-by: Gluster Build System <jenkins.com>
>
> It looks like whatever change apple made to nfs in mavericks 10.9 really
> goofed stuff up. I don't have any 10.8 machines but does nfs work from those
> clients? Again thanks for all your help.
The real issue is really interoperability issues, there is nothing stopping us from fixing it.
You should provide a tcpdump from linux server in this fashion
# tcpdump -s0 -i <device> -w /tmp/tcpdump.cap host <mac_osx_client>
Attach it back here, where we can see what is going on.
Questions
- are you not able to mount NFS even on Linux clients from master branch code?
- Can you provide "sw_vers" output?
- Can you attach server nfs.log to this bugzilla?
Thanks
-- Harsha
Trying to mount from MAC i get this from the logs... Is this a fuse issue? [2014-08-12 16:49:42.482455] I [MSGID: 100030] [glusterfsd.c:2021:main] 0-/usr/local/sbin/glusterfs: Started running /usr/local/sbin/glusterfs version 3.7dev (args: /usr/local/sbin/glusterfs --volfile-server=10.4.2.21 --volfile-id=/glfs_vol01 /mnt/objstor01) [2014-08-12 16:49:42.483576] E [mount_darwin.c:249:gf_fuse_mount] 0-glusterfs-fuse: failed to open device (No such file or directory) [2014-08-12 16:49:42.483607] E [xlator.c:425:xlator_init] 0-fuse: Initialization of volume 'fuse' failed, review your volfile again (In reply to Eric Horwitz from comment #33) > Trying to mount from MAC i get this from the logs... Is this a fuse issue? > > > [2014-08-12 16:49:42.482455] I [MSGID: 100030] [glusterfsd.c:2021:main] > 0-/usr/local/sbin/glusterfs: Started running /usr/local/sbin/glusterfs > version 3.7dev (args: /usr/local/sbin/glusterfs --volfile-server=10.4.2.21 > --volfile-id=/glfs_vol01 /mnt/objstor01) > [2014-08-12 16:49:42.483576] E [mount_darwin.c:249:gf_fuse_mount] > 0-glusterfs-fuse: failed to open device (No such file or directory) > [2014-08-12 16:49:42.483607] E [xlator.c:425:xlator_init] 0-fuse: > Initialization of volume 'fuse' failed, review your volfile again Did you install 'osxfuse' from brew? yes I did brew install osxfuse Warning: osxfuse-2.7.0 already installed sw_vers ProductName: Mac OS X ProductVersion: 10.9.2 BuildVersion: 13C64 gluster volume set nfs.disable yes then gluster volume set nfs.disable no allowed nfs to linux clients to work again.... bash-3.2# df -h /mnt/gfs Filesystem Size Used Avail Capacity iused ifree %iused Mounted on glusterfsd@osxfuse0 698Gi 394Gi 304Gi 57% 103367279 79566463 57% /mnt/gfs bash-3.2# sw_vers ProductName: Mac OS X ProductVersion: 10.9.4 BuildVersion: 13E28 bash-3.2# Not able to reproduce this behavior. Even the volume is created on the same box bash-3.2# gluster volume info Volume Name: p2p Type: Distribute Volume ID: d3eaa9bc-c5e9-4e29-948d-e9c17bfc3a85 Status: Started Number of Bricks: 1 Transport-type: tcp Bricks: Brick1: 10.0.0.46:/mnt/gfs1 bash-3.2# One thing to verify would be do you have?? # ls /dev/osxfuse* /dev/osxfuse0 /dev/osxfuse11 /dev/osxfuse14 /dev/osxfuse17 /dev/osxfuse2 /dev/osxfuse22 /dev/osxfuse4 /dev/osxfuse7 /dev/osxfuse1 /dev/osxfuse12 /dev/osxfuse15 /dev/osxfuse18 /dev/osxfuse20 /dev/osxfuse23 /dev/osxfuse5 /dev/osxfuse8 /dev/osxfuse10 /dev/osxfuse13 /dev/osxfuse16 /dev/osxfuse19 /dev/osxfuse21 /dev/osxfuse3 /dev/osxfuse6 /dev/osxfuse9 I do not have any of the osxfuse files in dev.... Maybe a reinstall of fuse? that worked... I also needed to do the following.... sudo /bin/cp -RfX /usr/local/opt/osxfuse/Library/Filesystems/osxfusefs.fs /Library/Filesystems sudo chmod +s /Library/Filesystems/osxfusefs.fs/Support/load_osxfusefs Glad it worked, let me know how it goes. FUSE based implementation should be much more reliable than using NFS IMHO. BTW do you happen to gather the tcpdump? and nfs.log it would help us look into NFS issue further. Created attachment 926198 [details]
Here is the nfs.log file
So I have some questions regarding performance. I have 4 machines with small RAID0 arrays that each get 150+MB/s throughput. This is setup with 2 stripes and 2 replicas. Everything is on 1Gbe. I am seeing 53MB/s write and 110MB/s read. Does this sound correct? Created attachment 926199 [details]
tcpdump of NFS mounted MAC 10.9 system
I captured the logs before mounting the share via NFS and then tried to ls -l the path which just sits and hangs.
(In reply to Eric Horwitz from comment #44) > So I have some questions regarding performance. I have 4 machines with small > RAID0 arrays that each get 150+MB/s throughput. This is setup with 2 stripes > and 2 replicas. Everything is on 1Gbe. I am seeing 53MB/s write and 110MB/s > read. Does this sound correct? That sounds correct replicate takes away 50% of the bandwidth due to synchronous replication (hitting both the servers at the same time) - read is always served from one of the servers at a point in time. For more architectural discussion - you should move this discussion to 'gluster-users' list. Okay so was able to mount and also was able to write a file but when i do a 'ls' the mount hangs bash-3.2# mount_nfs -o vers=3 10.14.19.108:/patchy /mnt/ gfs/ sshfs/ bash-3.2# mount_nfs -o vers=3 10.14.19.108:/patchy /mnt/gfs bash-3.2# cd /mnt/gfs bash-3.2# touch a bash-3.2# stat a 436207619 11617678988833378175 -rw-r--r-- 1 root wheel 0 0 "Aug 12 16:23:47 2014" "Aug 12 16:23:47 2014" "Aug 12 16:23:47 2014" "Aug 12 16:23:47 2014" 1048576 0 0 a bash-3.2# ls -l ^C All i can see is on Linux NFS server, so in-fact it looks like a READDIR bug it causes infinite loops. Must be some sort of an overflow which OSX NFS client doesn't understand - this would require some time to get it fixed. [2014-08-12 20:25:51.828257] D [nfs3-helpers.c:3485:nfs3_log_readdir_res] 0-nfs-nfsv3: XID: a7789414, READDIR: NFS: 0(Call completed successfully.), POSIX: 117(Structure needs cleaning), count: 32768, cverf: 17639020, is_eof: 0 [2014-08-12 20:25:51.931971] D [nfs3-helpers.c:3531:nfs3_log_readdir_call] 0-nfs-nfsv3: XID: a7789415, READDIR: args: FH: exportid fecd9929-ff89-45ea-adc7-5bbd39eb3cc8, gfid 00000000-0000-0000-0000-000000000001, count: 32768 [2014-08-12 20:25:51.933740] D [nfs3-helpers.c:3485:nfs3_log_readdir_res] 0-nfs-nfsv3: XID: a7789415, READDIR: NFS: 0(Call completed successfully.), POSIX: 117(Structure needs cleaning), count: 32768, cverf: 17639020, is_eof: 0 [2014-08-12 20:25:52.032864] D [nfs3-helpers.c:3531:nfs3_log_readdir_call] 0-nfs-nfsv3: XID: a7789416, READDIR: args: FH: exportid fecd9929-ff89-45ea-adc7-5bbd39eb3cc8, gfid 00000000-0000-0000-0000-000000000001, count: 32768 [2014-08-12 20:25:52.034827] D [nfs3-helpers.c:3485:nfs3_log_readdir_res] 0-nfs-nfsv3: XID: a7789416, READDIR: NFS: 0(Call completed successfully.), POSIX: 117(Structure needs cleaning), count: 32768, cverf: 17639020, is_eof: 0 [2014-08-12 20:25:52.195200] D [nfs3-helpers.c:3531:nfs3_log_readdir_call] 0-nfs-nfsv3: XID: a7789417, READDIR: args: FH: exportid fecd9929-ff89-45ea-adc7-5bbd39eb3cc8, gfid 00000000-0000-0000-0000-000000000001, count: 32768 [2014-08-12 20:25:52.196712] D [nfs3-helpers.c:3485:nfs3_log_readdir_res] 0-nfs-nfsv3: XID: a7789417, READDIR: NFS: 0(Call completed successfully.), POSIX: 117(Structure needs cleaning), count: 32768, cverf: 17639020, is_eof: 0 [2014-08-12 20:25:52.301950] D [nfs3-helpers.c:3531:nfs3_log_readdir_call] 0-nfs-nfsv3: XID: a7789418, READDIR: args: FH: exportid fecd9929-ff89-45ea-adc7-5bbd39eb3cc8, gfid 00000000-0000-0000-0000-000000000001, count: 32768 [2014-08-12 20:25:52.304043] D [nfs3-helpers.c:3485:nfs3_log_readdir_res] 0-nfs-nfsv3: XID: a7789418, READDIR: NFS: 0(Call completed successfully.), POSIX: 117(Structure needs cleaning), count: 32768, cverf: 17639020, is_eof: 0 [2014-08-12 20:25:52.398762] D [nfs3-helpers.c:3531:nfs3_log_readdir_call] 0-nfs-nfsv3: XID: a7789419, READDIR: args: FH: exportid fecd9929-ff89-45ea-adc7-5bbd39eb3cc8, gfid 00000000-0000-0000-0000-000000000001, count: 32768 [2014-08-12 20:25:52.400700] D [nfs3-helpers.c:3485:nfs3_log_readdir_res] 0-nfs-nfsv3: XID: a7789419, READDIR: NFS: 0(Call completed successfully.), POSIX: 117(Structure needs cleaning), count: 32768, cverf: 17639020, is_eof: 0 [2014-08-12 20:25:52.503713] D [nfs3-helpers.c:3531:nfs3_log_readdir_call] 0-nfs-nfsv3: XID: a778941a, READDIR: args: FH: exportid fecd9929-ff89-45ea-adc7-5bbd39eb3cc8, gfid 00000000-0000-0000-0000-000000000001, count: 32768 [2014-08-12 20:25:52.505680] D [nfs3-helpers.c:3485:nfs3_log_readdir_res] 0-nfs-nfsv3: XID: a778941a, READDIR: NFS: 0(Call completed successfully.), POSIX: 117(Structure needs cleaning), count: 32768, cverf: 17639020, is_eof: 0 [2014-08-12 20:25:52.624283] D [nfs3-helpers.c:3531:nfs3_log_readdir_call] 0-nfs-nfsv3: XID: a778941b, READDIR: args: FH: exportid fecd9929-ff89-45ea-adc7-5bbd39eb3cc8, gfid 00000000-0000-0000-0000-000000000001, count: 32768 [2014-08-12 20:25:52.626307] D [nfs3-helpers.c:3485:nfs3_log_readdir_res] 0-nfs-nfsv3: XID: a778941b, READDIR: NFS: 0(Call completed successfully.), POSIX: 117(Structure needs cleaning), count: 32768, cverf: 17639020, is_eof: 0 [2014-08-12 20:25:52.775226] D [nfs3-helpers.c:3531:nfs3_log_readdir_call] 0-nfs-nfsv3: XID: a778941c, READDIR: args: FH: exportid fecd9929-ff89-45ea-adc7-5bbd39eb3cc8, gfid 00000000-0000-0000-0000-000000000001, count: 32768 [2014-08-12 20:25:52.777282] D [nfs3-helpers.c:3485:nfs3_log_readdir_res] 0-nfs-nfsv3: XID: a778941c, READDIR: NFS: 0(Call completed successfully.), POSIX: 117(Structure needs cleaning), count: 32768, cverf: 17639020, is_eof: 0 [2014-08-12 20:25:52.909012] D [nfs3-helpers.c:3531:nfs3_log_readdir_call] 0-nfs-nfsv3: XID: a778941d, READDIR: args: FH: exportid fecd9929-ff89-45ea-adc7-5bbd39eb3cc8, gfid 00000000-0000-0000-0000-000000000001, count: 32768 [2014-08-12 20:25:52.910975] D [nfs3-helpers.c:3485:nfs3_log_readdir_res] 0-nfs-nfsv3: XID: a778941d, READDIR: NFS: 0(Call completed successfully.), POSIX: 117(Structure needs cleaning), count: 32768, cverf: 17639020, is_eof: 0 -- Harsha Created attachment 926220 [details] NFS ganesha configs I was able to get NFS client on MacOSX working with nfs-ganesha + FSAL_gluster support [1] Attached configs used for sample test. [1] - https://github.com/nfs-ganesha/nfs-ganesha/tree/master/src/FSAL/FSAL_GLUSTER I don't know if we have thought about deprecating GlusterNFS, but it would seem like NFS-Ganesha would be certainly the better approach. REVIEW: http://review.gluster.org/8476 (porting: OSX/Darwin 10.9 porting issues) posted (#1) for review on dht-stale-layout-fixes by Raghavendra G (rgowdapp) > I don't know if we have thought about deprecating GlusterNFS, but it
> would seem like NFS-Ganesha would be certainly the better approach.
Maybe start that discussion on gluster-devel or gluster-users mailing list?
(In reply to Anand Avati from comment #49) > REVIEW: http://review.gluster.org/8476 (porting: OSX/Darwin 10.9 porting > issues) posted (#1) for review on dht-stale-layout-fixes by Raghavendra G > (rgowdapp) This patch has been abandoned, it was probably not related anyway. I think this is a duplicate of bug 1132391. Could someone check/verify the patch from http://review.gluster.org/8509 ? It's been merged in the master branch already, so you could probably test it there too. Thanks, Niels I'm now marking this as a duplicate of Bug 1132391. Please re-open if this does not fix the reported issue with Gluster/NFS and a stripe volume when mounting from OSX. *** This bug has been marked as a duplicate of bug 1132391 *** |