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:
None 
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
Description:
The standard 32-bit binary can't create files > 2G for InnoDB.  The -64bit binary works just fine.

Examples of things that don't work:

* create a 3G ibdata1 file
* use the default innodb_data_file_path, and insert more than 2G of data
* use the --innodb_file_per_table option, and insert more than 2G of data

However, MyISAM doesn't have a problem creating large files.  I created a 3G .MYD file.

I tested it on hpux11, which is:
HP-UX hpux11 B.11.11 U 9000/800 907027856 unlimited-user license

The filesystem is VxFS, in case that might play some role (doesn't seem likely, since making files > 2G is certainly possible).

How to repeat:

Grab our binary:

http://dev.mysql.com/get/Downloads/MySQL-4.1/mysql-standard-4.1.6-gamma-hp-hpux11.11-hppa2...

After mysql_install_db, start the server with --innodb_data_file_path=ibdata1:6G

It stops, spewing this to stderr:

$ Starting mysqld daemon with databases from /home/mysqldev/tsmith/m/data

msgcnt 9814 vxfs: mesg 001: vx_nospace - /dev/vg00/lvol5 file system full (1 block extent)
STOPPING server from pid file /home/mysqldev/tsmith/m/data/hpux11.pid
041021 00:20:56  mysqld ended

The error log shows this:

041021 00:20:30  mysqld started
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
041021  0:20:30  InnoDB: Setting file ./ibdata1 size to 3072 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200 300041021  0:20:56  InnoDB: Error: Write to file ./ibdata1 failed at offset 0 411041792.
InnoDB: 8388608 bytes should have been written, only 4210688 were written.
InnoDB: Operating system error number 2.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: Error number 2 means 'No such file or directory'.
InnoDB: See also section 13.2 at http://www.innodb.com/ibman.php
InnoDB: about operating system error numbers.
InnoDB: Error in creating ./ibdata1: probably out of disk space
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!
041021  0:20:56  [ERROR] Can't init databases
041021  0:20:56  [ERROR] Aborting

041021  0:20:56  [NOTE] /home/mysqldev/tsmith/m/bin/mysqld: Shutdown complete

041021 00:20:56  mysqld ended

Suggested fix:

Unknown
[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.