|
From: | Brent A Nelson |
Subject: | [Gluster-devel] NFS reexport still a little glitchy |
Date: | Wed, 25 Jul 2007 16:16:51 -0400 (EDT) |
2007-07-25 14:36:43 E [afr.c:1234:afr_selfheal_getxattr_cbk] mirror2: (path=/nfs2/share/zoneinfo/right/Pacific/Johnston child=share2-1) op_ret=-1 op_errno=61 2007-07-25 14:36:43 E [afr.c:1234:afr_selfheal_getxattr_cbk] ns0: (path=/nfs2/share/zoneinfo/right/Pacific/Johnston child=ns0-0) op_ret=-1 op_errno=61 2007-07-25 14:36:43 E [afr.c:1234:afr_selfheal_getxattr_cbk] ns0: (path=/nfs2/share/zoneinfo/right/Pacific/Johnston child=ns0-1) op_ret=-1 op_errno=61
In my tests from today's TLA repository, nfsd is eventually even hanging (this wasn't occurring in earlier patch releases). Following that, I did an ls from the GlusterFS reexport machine of one of the areas that the NFS client recently complained about and got a similar error, but in a different function:
2007-07-25 15:51:10 E [afr.c:563:afr_getxattr_cbk] mirror4: (path=/usr/share/dict child=share4-0) op_ret=-1 op_errno=61 2007-07-25 15:51:10 E [afr.c:563:afr_getxattr_cbk] mirror4: (path=/usr/share child=share4-0) op_ret=-1 op_errno=61
I'm hoping the errors provide some clue to the NFS glitches (and presumably pins the issue down to AFR), but perhaps they're harmless. Any ideas?
Thanks, BrentPS An NFS reexport from an extremely simple (no protocol/*, no unify, no AFR; only storage/posix) GlusterFS volume last week seemed fast and trouble-free. If anyone needs NFS reexport and doesn't need AFR, I haven't tested it (yet), but it's definitely worth a shot!
[Prev in Thread] | Current Thread | [Next in Thread] |