| Bug #6189 | 32-bit HPUX binary; InnoDB can't create files bigger than 2G | ||
|---|---|---|---|
| Submitted: | 20 Oct 2004 22:30 | Modified: | 12 Mar 2005 14:58 |
| Reporter: | Timothy Smith | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S2 (Serious) |
| Version: | 4.1.5 | OS: | HP/UX (HPUX 11.11) |
| Assigned to: | Heikki Tuuri | CPU Architecture: | Any |
[20 Oct 2004 22:30]
Timothy Smith
[21 Oct 2004 9:40]
Heikki Tuuri
Hi!
A really strange bug. It seems to be able to write only 396 MB and 16 kB of data!
I think I found the bug. The 32-bit binary is probably compiled with HP-UX-10.20. And configure.in says that pread() is broken in HP-UX-11.*.
Fix: maybe we should enable -DHAVE_BROKEN_PREAD in configure.in also for HP-UX-10.20?
Regards,
Heikki
configure.in:
*hpux10.20*)
echo "Enabling workarounds for hpux 10.20"
CFLAGS="$CFLAGS -DHAVE_BROKEN_SNPRINTF -DSIGNALS_DONT_BREAK_READ -DDO_NOT_R\
EMOVE_THREAD_WRAPPERS -DHPUX10 -DSIGNAL_WITH_VIO_CLOSE -DHAVE_BROKEN_PTHREAD_CO\
ND_TIMEDWAIT -DHAVE_POSIX1003_4a_MUTEX"
CXXFLAGS="$CXXFLAGS -DHAVE_BROKEN_SNPRINTF -D_INCLUDE_LONGLONG -DSIGNALS_DO\
NT_BREAK_READ -DDO_NOT_REMOVE_THREAD_WRAPPERS -DHPUX10 -DSIGNAL_WITH_VIO_CLOSE \
-DHAVE_BROKEN_PTHREAD_COND_TIMEDWAIT -DHAVE_POSIX1003_4a_MUTEX"
if test "$with_named_thread" = "no"
then
echo "Using --with-named-thread=-lpthread"
with_named_thread="-lcma"
fi
;;
*hpux11.*)
echo "Enabling workarounds for hpux 11"
CFLAGS="$CFLAGS -DHPUX11 -DHAVE_BROKEN_PREAD -DDONT_USE_FINITE -DHAVE_BROKE\
N_GETPASS -DNO_FCNTL_NONBLOCK -DDO_NOT_REMOVE_THREAD_WRAPPERS -DHAVE_BROKEN_PTH\
READ_COND_TIMEDWAIT"
CXXFLAGS="$CXXFLAGS -DHPUX11 -DHAVE_BROKEN_PREAD -DDONT_USE_FINITE -D_INCLU\
DE_LONGLONG -DNO_FCNTL_NONBLOCK -DDO_NOT_REMOVE_THREAD_WRAPPERS -DHAVE_BROKEN_P\
THREAD_COND_TIMEDWAIT"
os0file.c:
#if defined(HAVE_PWRITE) && !defined(HAVE_BROKEN_PREAD)
os_mutex_enter(os_file_count_mutex);
os_file_n_pending_pwrites++;
os_mutex_exit(os_file_count_mutex);
ret = pwrite(file, buf, n, offs);
os_mutex_enter(os_file_count_mutex);
os_file_n_pending_pwrites--;
os_mutex_exit(os_file_count_mutex);
if (srv_unix_file_flush_method != SRV_UNIX_LITTLESYNC
&& srv_unix_file_flush_method != SRV_UNIX_NOSYNC
&& !os_do_not_call_flush_at_each_write) {
/* Always do fsync to reduce the probability that when
the OS crashes, a database page is only partially
physically written to disk. */
ut_a(TRUE == os_file_flush(file));
}
return(ret);
#else
{
ulint i;
/* Protect the seek / write operation with a mutex */
i = ((ulint) file) % OS_FILE_N_SEEK_MUTEXES;
os_mutex_enter(os_file_seek_mutexes[i]);
ret = lseek(file, offs, 0);
[30 Oct 2004 7:31]
Heikki Tuuri
Hi! Please test again with 4.1.7, though I doubt the problem has been fixed with a couple of simple typecasts. --Heikki
[31 Oct 2004 9:37]
Heikki Tuuri
Tim, another user reported on Wednesday that it was able to write exactly 2 GB to the data file. Are you sure that you did not run out of disk space when you tested? Regards, Heikki
[21 Dec 2004 17:26]
Heikki Tuuri
Hi! This bug is fixed in upcoming 4.1.9 and 4.0.23. http://lists.mysql.com/internals/19917 and http://lists.mysql.com/internals/19922 fix it in 4.0. The reason for the bug was that InnoDB used a 32-bit integer as the return value of lseek(). The bug only manifested on HP-UX (32-bit binaries) because it is the only platform where HAVE_BROKEN_PREAD is defined. Regards, Heikki
[21 Dec 2004 17:36]
Heikki Tuuri
Hi! The fix did not make it to 4.0.23. It will be in 4.0.24. Regards, Heikki
[12 Mar 2005 14:58]
Heikki Tuuri
Fixed in 4.1.9 and 4.0.24.
