[Gluster-users] Samba > NFS > Gluster leads to runaway lock problem after many stable months

[Whit Blauvelt]

On Thu, Aug 30, 2012 at 06:12:46PM +0100, Brian Candler wrote:
> On Thu, Aug 30, 2012 at 09:44:30AM -0400, Whit Blauvelt wrote:

> > Given that my XFS Gluster NFS mount does not have inode64 set (although it's
> > only 500G, not the 2T barrier beyond which that's evidently strictly
> > required), and the likelihood that that led to yesterday's problem, what's
> > the course to fix this? 
> 
> I very much doubt that was the problem.
> 
> The whole reason that inode64 is not the default is so that inode numbers
> are kept in the range less than 2^32, precisely so that ancient NFS clients
> can deal with them.

My reason for suspecting it is that Samba is doing 64-bit, and the NFS
client is recent enough to work with 64-bit - whether Gluster as NFS server
is doing 64-bit I don't know - and with XFS by default as 32-bit rather than
64 ... well the question is what caused Samba and lockd to get into such a
noisey conflict. Given the smallish size of the Gluster NFS mount, seems odd
for it to run beyond 32-bit space. Maybe it didn't. But if it _was_ a 64-bit
32-bit mismatch, setting XFS to be 64-bit might be advised.

Then again, if I understand Samba's "posix locks" option right, having that
off might avoid the problem, whether or not its a 64-bit to 32-bit mismatch.
But I haven't found a clear description of the full implications of posix
locks, beyond the suggestion that Samba has its own, independent file
locking independent of the file system's, which it should use with this
turned off. Does that independence go so far as to leave lockd out of it? 

Trying to guess the odds that turning that off will result in no repetition,
since the system in question is the definition of "mission critical."

Thanks,
Whit