[Samba] Re: locking.tdb: expand_file ftruncate to 8192 failed
jra at samba.org
Thu Sep 22 15:19:18 GMT 2005
On Thu, Sep 22, 2005 at 10:15:08AM +0200, Axel Thimm wrote:
> On Wed, Sep 21, 2005 at 04:34:32PM -0700, Jeremy Allison wrote:
> > On Thu, Sep 22, 2005 at 01:01:45AM +0200, Axel Thimm wrote:
> > > Should I generate a more verbose debug log (what log level
> > > settings?) and place it somewhere on the net?
> > >
> > > I wonder how I'm triggering that code path, it certainly isn't seen by
> > > the typical RHEL4 installs. The lock directory is set to reside on a
> > > GFS filesystem, could that make a difference (shouldn't as it is
> > > supposed to be POSIX compliant local-fs-like filesystem)?
> > Oh almost certainly that's the problem. Did you test my test program
> > on a GFS filesystem ? Doesn't GFS use crypto credentials to prevent
> > people hijacking root ? If that's the case I bet they break POSIX
> > semantics w.r.t. this.
> > Why are you putting the locking db on a GFS filesystem anyway. That's
> > madness !
> The reason is to have a poor-man's-clustered-samba by placing lock and
> private dir on a common share and have the relocated smbd/nmbd pairs
> access them. E.g. relocating within the cluster is effectively like
> restarting smbd/nmbd on a node.
That's never going to work (at least with acceptable speed). Talk
to Volker for details...
> (gdb) run testfile thimm
> Starting program: /srv/physik.fu-berlin.de/data/samba-test/a.out testfile thimm
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000003e18a6fb00 in strlen () from /lib64/tls/libc.so.6
> (gdb) bt
> #0 0x0000003e18a6fb00 in strlen () from /lib64/tls/libc.so.6
> #1 0x0000003e18a428dc in vfprintf () from /lib64/tls/libc.so.6
> #2 0x0000003e18a3f299 in buffered_vfprintf () from /lib64/tls/libc.so.6
> #3 0x0000003e18a3f479 in vfprintf () from /lib64/tls/libc.so.6
> #4 0x0000003e18a47d96 in fprintf () from /lib64/tls/libc.so.6
> #5 0x0000000000400b2b in main (argc=3, argv=0x7fbffff8a8) at test.c:55
Very strange - that's this line :
fprintf(stderr, "failed to extend file %s - error %s\n",
argv, strerror(errno) );
I wonder if strerror is returning NULL ?
> > As I said, I bet GFS isn't POSIX complient. Don't put locking
> > tdb's on anything but local filesystems.
> Well, GFS claims to be POSIX and local-like in any way. Maybe it is
> just a bug in GFS? Does POSIX ensure that you can open an fd under
> some user and not lose access right to the fd when dropping
Yes. That's why we wrote it this way. It's a bug in GFS. Open it
More information about the samba