This one's starting to give me fits, especially as it makes it impossible to catch LORs. The configuration is admittedly fairly complex - the actual NFS server is Linux using CTDB for a 4-way cluster overtop a GlusterFS non-Ganesha cluster. Going to NFSv3 would possibly resolve it. But it's fixing it in exactly the same way as rebuilding the release with the
Of course, the similarly built FreeBSD cluster (3-way CARP overtop of GlusterFS non-Ganesha) does not have this issue. But moving these filesystems is simply not an option either.
Surely someone out there's run into this, and figured out a more rational way to solve it either at the client or server. Maybe some option I missed. There was some discussion about it back in August, and prior to that in 2011, but it looks like nothing really came out of it from client side aside from resolving potential breakage.
I looked at r297881 from April (shout to rmacklem@ for pNFS!), but this doesn't seem to actually resolve the issue either aside from moving the message to the NFSCL_DEBUG macro.
printf removed.Of course, the similarly built FreeBSD cluster (3-way CARP overtop of GlusterFS non-Ganesha) does not have this issue. But moving these filesystems is simply not an option either.
Surely someone out there's run into this, and figured out a more rational way to solve it either at the client or server. Maybe some option I missed. There was some discussion about it back in August, and prior to that in 2011, but it looks like nothing really came out of it from client side aside from resolving potential breakage.
I looked at r297881 from April (shout to rmacklem@ for pNFS!), but this doesn't seem to actually resolve the issue either aside from moving the message to the NFSCL_DEBUG macro.
