I'm not sure if anyone is using mmap() either in the server or behind the
server for anything but I've been bitten by subtle problems under HP-UX
and BSDI 2.x in mSQL. I thought I may save someone a lot of frustration if
I mentioned it here.
mSQL uses mmap() where possible to map a database table into the server's
VM space. If an insert is received that causes the file to be extended
(i.e. there are no holes in the data that can be filled), the new table
row is appended to the table file. The table is flagged as needing a
remap before it the next read operaton.
On the next SELECT or UPDATE, the table region is unmapped and then
mapped again to ensure the new rows are available to the engine. This
works fine on most boxes (SunOS, Solaris, OSF1, FreeBSD, NetBSD, Linux
1.3.x etc) but fails on HP-UX and BSDI 2.x (worked on BSDI 1.x). It
appears that if you use write() to update a file while it is mapped,
HP-UX and BSDI get very confused, the result being that the newly written
data is trashed in a random way.
My fix was to unmap the region before starting to make updates and then
mapping it back when I'm done rathern than the update-unmap-map method I
had been using.
So, if this info is of use to you great. If not, you should have bounced
on the D key by now anyway :)
Bambi
...
server for anything but I've been bitten by subtle problems under HP-UX
and BSDI 2.x in mSQL. I thought I may save someone a lot of frustration if
I mentioned it here.
mSQL uses mmap() where possible to map a database table into the server's
VM space. If an insert is received that causes the file to be extended
(i.e. there are no holes in the data that can be filled), the new table
row is appended to the table file. The table is flagged as needing a
remap before it the next read operaton.
On the next SELECT or UPDATE, the table region is unmapped and then
mapped again to ensure the new rows are available to the engine. This
works fine on most boxes (SunOS, Solaris, OSF1, FreeBSD, NetBSD, Linux
1.3.x etc) but fails on HP-UX and BSDI 2.x (worked on BSDI 1.x). It
appears that if you use write() to update a file while it is mapped,
HP-UX and BSDI get very confused, the result being that the newly written
data is trashed in a random way.
My fix was to unmap the region before starting to make updates and then
mapping it back when I'm done rathern than the update-unmap-map method I
had been using.
So, if this info is of use to you great. If not, you should have bounced
on the D key by now anyway :)
Bambi
...