tdb_lock problem on gpfs filesystem

[Jeremy Allison]

On Thu, Nov 10, 2005 at 11:23:30AM +0100, Hansjörg Maurer wrote:
> Hi
> 
> I am running samba-3.0.20 on RHEL4 x86_64.
> Samba is part of a Linux-HA Cluster which usese IBM General Parallel
> Filesystem GPFS
> as shared storage.
> 
> Samba shoul run as a failover ha resource.
> Therefore we put all the samba resources (/etc/samba,  /var/lib/samba)
> und the clusterfilesystem.
> 
> When I start samba,
> samba prints messages like
> log.smbd:  tdb(/var/lib/samba/printing/PDFprinter.tdb): tdb_lock failed
> on list 201 ltype=1 (No locks available)
> 
> an strace shows
> 
> strace -e open,fcntl -f smbd
> 
> open("/var/lib/samba/printing/hp8000.tdb", O_RDWR|O_CREAT, 0600) = 19
> fcntl(19, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=1}) = 0
> fcntl(19, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=1}) = 0
> fcntl(19, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=6140, len=1}) = 0
> fcntl(19, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=6140, len=1}) = 0
> open("/var/lib/samba/printing/hp5m.tdb", O_RDWR|O_CREAT, 0600) = 19
> fcntl(19, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=1}) = 0
> fcntl(19, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=1}) = 0
> fcntl(19, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=6140, len=1}) = 0
> fcntl(19, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=6140, len=1}) = 0
> open("/var/lib/samba/printing/hp5000hf.tdb", O_RDWR|O_CREAT, 0600) = 19
> fcntl(19, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=1}) = 0
> fcntl(19, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=1}) = 0
> fcntl(19, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=6140, len=1})
> = -1 ENOLCK (No locks available)
> open("/usr/share/locale/locale.alias", O_RDONLY) = 20
> 
> I  was trying to get rid of this messages with -DHAVE_MMAP=0 
> -DTDB_DEBUG=1 -DNOLOCK=1
> in source/tdb/Makefile
> 
> I also set
> use mmap= no
> in smb.conf
> with no success (gpfs seems to have  sometimes problems with mmap files)
> Does anyone has an idea how I can trace down the problem?

I think you'll need to talk with IBM on this. tdb makes some heavy
requests of a shared filesystem (the POSIX lock semantics muct be
exactly correct) which few other applications need.

Jeremy.