[Pkg-samba-maint] Bug#759008: Bug#759008: libtdb1: FTBFS on hurd-i386

[Jelmer Vernooij]

On Sat, Aug 23, 2014 at 10:56:11PM +0200, Manuel Menal wrote:
> On 23/08/2014 22:27, Jelmer Vernooij wrote:
> >On Sat, Aug 23, 2014 at 02:30:33PM -0400, Manuel Menal wrote:
> >>tdb fails to build on hurd-i386 (blocking ldb and thus samba) because
> >>it uses two features that are not yet implemented on GNU/Hurd: msync(1)
> >>and partial file locking.
> >>
> >>You'll find attached two small patches that make it build.
> >>
> >>The first patch adds a configure test for partial file locking and make
> >>tdb use whole file locking when it's not supported.
> >>
> >>The second one adds a configure test for msync(1) and correct tdb's
> >>code accordingly.
> >>
> >>Please note that this package should be built with 'nocheck' because
> >>some tests do not run well without partial file locking. The tools in
> >>tdbtools/ run fine though.
> >>
> >>Please also note that hurd-any should be added to debian/control so it
> >>gets built on hurd-i386.
> >The whole point of tdb is that it allows multiple concurrent
> >readers/writers, and that is why the various applications that depend
> >on tdb use it.
> Yes, I get that. But that doesn't mean it doesn't work without this patch,
> since samba actually works with this, which was the point.
Does Samba's "make test" (not run as part of the package build at the
moment) pass, or does it just pass a few smoke tests?

> >This patch might make tdb build, but it makes it pointless. Any
> >patches to fix tdb on the Hurd the should also pass the test
> >suite, or downstream users risk database corruption and/or other
> >issues.
> The only tests that fail are those which check specifically for partial file
> locking (test/lock-tracking.c specifically checks for lock overlaps, which
> of course happen since the whole file is locked; which makes
> run-die-during-transaction and run-no-lock-during-traverse fail).
Then please patch it out so that test doesn't run on the hurd. There
is no excuse *not* to run the test suite.

> I fail to see how it could cause database corruption, since, indeed, the
> whole file is always locked. The only thing it does (as you rightly pointed
> out) is limit functionality.
You disable msync. If you do that, then please disable mmap
*entirely*.

If it's just the tests related to byte range locking that fail, then
that's probably fine. Let's run the other tests though and make sure *they* pass.

Still, the contention is going to be horrible if locking happens on a file
level - and there might be deadlocks in applications depending on tdb.

What is the output of "./bin/tdbtorture -n 10" on the Hurd, and how
long does it take to run?

> >Please fix byte range locking in the Hurd (see the blocking bug I've
> >added), or propose a patch that uses an alternative *and* passes the
> >test suite.
> I do hope too that partial file locking gets implemented on GNU/Hurd ASAP.
> But in the meantime, it would be a shame not to have a working samba, when
> it *does* work fine with this patch.
I'm not convinced this will actually get you a well working Samba. It
certainly won't get you a Samba that has reasonable performance in a
multi-user environment.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20140824/1089e570/attachment.sig>