TDB on OpenBSD problem.
don_mccall at hp.com
Tue May 8 20:47:33 GMT 2001
As someone else on the list responded, this problem is basically because on
we don't have a unified buffer cache; the mmap stuff uses page cache and the
uses buffer cache - we're looking at implementing a unified buffer cache in
major HP-UX release, but that doesn't help here. As far as limits, if we
mmap shared, then basically we are not limited - a 32bit implementation has
1.9GIG of shared space across all processes running on HP-UX, and individual
are not limited on the size of shared mmap'ings, as this goes into the
instead of the data segment space, which WOULD be limited by the maxdsize
parameter (tunealble...). So I think Jeremy's fix should be applicable on
well; unmapping before any lseeks, etc, and then remapping (assuming that
buffers have been flushed to the file before the remapping) should ensure
Hope this helps,
"Reason, not volume, is the primary
differentiator between a discussion, and an
From: tridge at samba.org [mailto:tridge at samba.org]
Sent: Saturday, May 05, 2001 10:02 PM
To: don_mccall at hp.com
Cc: jeremy at valinux.com; vmn at bom.gov.AU; samba-technical at lists.samba.org
Subject: Re: TDB on OpenBSD problem.
> The application must ensure correct synchronization when using mmap()
> in conjunction with any other file access method, such as read() and
> write(), standard input/output, and shmat().
But does it say *how* that synchronisation can be done by the app??
This sounds like a cop-out to me. "we can't work out how to do it -
its the apps responsibility".
> So I added a call to msync() right before the call to test() to the test
> program, and with this I resolve the inconsistency on the 11.0 box I was
> seeing the error on.
an msync() is potentially very expensive. It might even be faster to
drop mmap support on HPUX and use read/write.
The patch jeremy committed seems to work for simple cases, but I'm
concerned that it leaves us with a potential problem if the database
grows beyond the size allowed for mmap by the rlimits for the
process. In that case some of the smbds will drop back to read/write
IO and thus will become inconsistent with the ones that are still
Is this a serious enough problem to worry about? I'm not sure. Can
someone tell me what limits apply to mmap size on HPUX? I tested on
OpenBSD 2.5 and it appears that none of the limits from "ulimit -a"
affect mmap size, so the fix should be OK there.
More information about the samba-technical