RE: mysqldump: Got errno 27 on write. file too large
Hello again
Finaly looking in the old doc, I saw that mysql was compiled on Solaris 2.6 and
I have the following track for the configure step at that time:
checking for CFLAGS value to request large file support... -D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64
checking for LDFLAGS value to request large file support...
checking for LIBS value to request large file support...
checking for _FILE_OFFSET_BITS... 64
checking for _LARGEFILE_SOURCE... 1
checking for _LARGE_FILES... no
checking for size_t... yes
checking for dirent.h that defines DIR... yes
The problem could be there. Is that make sense?
Thank you again
-Message d'origine-
De : Duhaime Johanne [mailto:[EMAIL PROTECTED]
Envoyé : Friday, 07 July 2006 16:37
À : Daniel da Veiga; mysql@lists.mysql.com
Objet : RE: mysqldump: Got errno 27 on write. file too large
Thank you
Of course this is a bad new. Much easier to upgrade to Mysql 5 than to change
the Kernel.
uname -a
SunOS mercure 5.9 Generic_118558-04 sun4u sparc SUNW,Ultra-80
I do not have fstab but vfstab
mercure{root}171: more vfstab
#device device mount FS fsckmount mount
#to mount to fsck point typepassat boot options
#
#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1 yes -
fd - /dev/fd fd - no -
/proc - /proc proc- no -
/dev/dsk/c0t0d0s1 - - swap- no -
/dev/dsk/c0t1d0s1 - - swap- no -
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 no
-
/dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /varufs 1 no
-
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /optufs 1 yes
-
/dev/dsk/c2t5d0s0 /dev/rdsk/c2t5d0s0 /seqweb ufs 1 yes
-
/dev/dsk/c2t5d0s5 /dev/rdsk/c2t5d0s5 /oracle ufs 1 yes
-
/dev/dsk/c2t5d0s6 /dev/rdsk/c2t5d0s6 /dbsufs 1 yes
-
/dev/dsk/c1t5d0s2 /dev/rdsk/c1t5d0s2 /seqdataufs 1
yes -
terre:/opt/net - /opt/netnfs - yes bg,soft,retry=10
#terre:/opt/samba - /opt/sambanfs - yes
bg,soft,retry=10
terre:/opt/CiscoSecure - /opt/CiscoSecurenfs - yes
bg,soft,retry=10
#terre:/archives - /archives nfs - yes
bg,soft,retry=10
titan:/var/mail - /var/mail nfs - yes
actimeo=0,bg,soft,retry=10
swap- /tmptmpfs - yes -
-Message d'origine-
De : Daniel da Veiga [mailto:[EMAIL PROTECTED] Envoyé : Friday, 07 July 2006
13:38 À : mysql@lists.mysql.com Objet : Re: mysqldump: Got errno 27 on write.
file too large
On 7/7/06, Duhaime Johanne [EMAIL PROTECTED] wrote:
Thank you to both of you.
Just a add-on, already mentionned to Michael:
My file system allows illimited files size.
I have a file of 11G on my partition.
mercure{root}120: du -kh mercure.log.jui2006
11G mercure.log.jui2006
The owner of this file is mysql (it is the log file).
Also the sysadmin was able to create files of big size with the mkfile
command with Mysql account.
I have gone througt the change history looking for the work mysqldump and I
have not seen anythng related.
So I guest my best guess is to install Mysql 5.
Sorry, but I think this isn't going to save you.
The error you mention (as Greg told you) is not a MySQL error, it is a kernel
error reported when dealing with files larger than 2GB. This is specially true
if you're using an old kernel, or old filesystem (but filesystem is not
important in this case, only if you use a really OLD fs). Your tests are no
good for this matter, as creating a file and writting it is a complete
different task. Check:
http://en.wikipedia.org/wiki/Wikipedia:Database_dump_import_problems#Got_error_27_from_table_handler
Please report your kernel version (output of uname -a) and filesystem types
(you can post your /etc/fstab file). You must use a current kernel in order to
use large files.
This may help you too:
http://cbbrowne.com/info/fs.html
Best regards
-Message d'origine-
De : Greg 'groggy' Lehey [mailto:[EMAIL PROTECTED] Envoyé : Wednesday,
05 July 2006 22:04 À : Duhaime Johanne; Michael Stassen Cc :
mysql@lists.mysql.com; Dominik Klein Objet : Re: mysqldump: Got errno
27 on write. file too large
On Wednesday, 5 July 2006 at 9:12:52 -0400, Duhaime Johanne wrote:
I have musql 4.1.7 on Solaris 9, 64 bits and I want to mysqldump a
+-4 gigas db.
...
The full directory that contains the *.frm, *.MYD,*.MYI files has
the following size:
du -ks /seqdata/mysql/autres_bds/regen
3702719 /seqdata/mysql/autres_bds/regen ... I get the output du -k:
2098184 myregendump
this error supposed to be:
bin/perror 27
Error code 27: File too large
As you can
RE: mysqldump: Got errno 27 on write. file too large
Thank you to both of you.
Just a add-on, already mentionned to Michael:
My file system allows illimited files size.
I have a file of 11G on my partition.
mercure{root}120: du -kh mercure.log.jui2006
11G mercure.log.jui2006
The owner of this file is mysql (it is the log file).
Also the sysadmin was able to create files of big size with the mkfile command
with Mysql account.
I have gone througt the change history looking for the work mysqldump and I
have not seen anythng related.
So I guest my best guess is to install Mysql 5.
Best regards
-Message d'origine-
De : Greg 'groggy' Lehey [mailto:[EMAIL PROTECTED]
Envoyé : Wednesday, 05 July 2006 22:04
À : Duhaime Johanne; Michael Stassen
Cc : mysql@lists.mysql.com; Dominik Klein
Objet : Re: mysqldump: Got errno 27 on write. file too large
On Wednesday, 5 July 2006 at 9:12:52 -0400, Duhaime Johanne wrote:
I have musql 4.1.7 on Solaris 9, 64 bits and I want to mysqldump a +-4
gigas db.
...
The full directory that contains the *.frm, *.MYD,*.MYI files has the
following size:
du -ks /seqdata/mysql/autres_bds/regen
3702719 /seqdata/mysql/autres_bds/regen ... I get the output du -k:
2098184 myregendump
this error supposed to be:
bin/perror 27
Error code 27: File too large
As you can see I have plenty of space.
Error codes below 128 come from the kernel. It's possible for applications to
return error numbers in this range too, but it's not a good idea, and mysqldump
doesn't do it. So whatever's happening here, it's being reported by the kernel.
There are two numbers:
#define EFBIG 27 /* File too large */
#define ENOSPC 28 /* No space left on device */
EFBIG refers to limitations in the size of one file; you can get it even if
there's plenty of space in the file system. ENOSPC is the other way round: you
can get it even if the file isn't at its maximum allowed size.
In the error file I have multiple times the line:
InnoDB: Error: unable to create temporary file; errno: 2
mercure{mysql}66: bin/perror 2
Error code 2: No such file or directory
But the directory exist.
I'd guess that it doesn't. Unfortunately the message doesn't tell you which
file it's trying to create. This might be worth a bug report, since it
seriously hinders you in finding out what that particular problem is.
Why does this not show up in your verbose mysqldump?
Then I tried a verbose mysqldump.
mercure{mysql}73: /seqweb/mysql/bin/mysqldump --opt --verbose regen
/seqdata/mysql/myregendump
-- Connecting to localhost...
-- Retrieving table structure for table cpgisland_Human_May2004...
-- Sending SELECT query...
-- Retrieving rows...
...
21 tables
-- Retrieving table structure for table unit_occurence_Human_May2004...
-- Sending SELECT query...
-- Retrieving rows...
/seqweb/mysql/bin/mysqldump: Got errno 27 on write This table is 1
giga data and 500mb index.
Note that mysqldump is not very efficient in its format. How big was the
output file when it failed? I'd hazard a guess at 2 GB (specifically,
2147483647 bytes). If this is the case, it's definitely a file system
limitation.
Then I tried a mysqldump of this table only:
/seqweb/mysql/bin/mysqldump --opt --verbose regen
unit_occurence_Human_May2004
and it works fine.
How can I solve this problem?
Well, you've found one workaround :-)
What file system are you using? Could this be (Sun's old) UFS?
I'm sure that Sun has file systems that aren't limited to 2 GB; you could use
one of them. They'll probably give you other advantages too.
I have looked at the previous message in the forum but could not find
anything answering my problem.
I'm relatively confident that this isn't a mysqldump problem.
On Wednesday, 5 July 2006 at 12:28:53 -0400, Michael Stassen wrote:
My first thought is that Dominik is on the right track. I get
: perror 27
OS error code 27: File too large
which suggests there is some OS limitation. Perhaps the user running
mysqldump is limited? Do you have any larger files owned by the same
user? Can that user currently create a file larger than that using
another means?
Yes, this could be a disk quota issue.
The other possibility would be a bug. You are using version 4.1.7,
which is nearly 2 years old now (released October 2004). The current
version is 4.1.20. If you have indeed hit a bug, your best bet would be to
upgrade
and try again. You should probably at least read the *long* list
of bug fixes from 4.1.7 to 4.1.20 in the MySQL change history in the
manual http://dev.mysql.com/doc/refman/4.1/en/news-4-1-x.html.
While it's my duty not to stand up and say it's not a mysqldump bug, I'd be
very surprised in this case--see above for reasoning.
Greg
--
Greg Lehey, Senior Software Engineer, Online Backup MySQL AB,
http://www.mysql.com/ Echunga, South Australia
Phone: +61-8-8388-8286 Mobile: +61-418-838-708
VoIP: sip:[EMAIL
Re: mysqldump: Got errno 27 on write. file too large
On 7/7/06, Duhaime Johanne [EMAIL PROTECTED] wrote:
Thank you to both of you.
Just a add-on, already mentionned to Michael:
My file system allows illimited files size.
I have a file of 11G on my partition.
mercure{root}120: du -kh mercure.log.jui2006
11G mercure.log.jui2006
The owner of this file is mysql (it is the log file).
Also the sysadmin was able to create files of big size with the mkfile command
with Mysql account.
I have gone througt the change history looking for the work mysqldump and I
have not seen anythng related.
So I guest my best guess is to install Mysql 5.
Sorry, but I think this isn't going to save you.
The error you mention (as Greg told you) is not a MySQL error, it is a
kernel error reported when dealing with files larger than 2GB. This is
specially true if you're using an old kernel, or old filesystem (but
filesystem is not important in this case, only if you use a really OLD
fs). Your tests are no good for this matter, as creating a file and
writting it is a complete different task. Check:
http://en.wikipedia.org/wiki/Wikipedia:Database_dump_import_problems#Got_error_27_from_table_handler
Please report your kernel version (output of uname -a) and
filesystem types (you can post your /etc/fstab file). You must use a
current kernel in order to use large files.
This may help you too:
http://cbbrowne.com/info/fs.html
Best regards
-Message d'origine-
De : Greg 'groggy' Lehey [mailto:[EMAIL PROTECTED]
Envoyé : Wednesday, 05 July 2006 22:04
À : Duhaime Johanne; Michael Stassen
Cc : mysql@lists.mysql.com; Dominik Klein
Objet : Re: mysqldump: Got errno 27 on write. file too large
On Wednesday, 5 July 2006 at 9:12:52 -0400, Duhaime Johanne wrote:
I have musql 4.1.7 on Solaris 9, 64 bits and I want to mysqldump a +-4
gigas db.
...
The full directory that contains the *.frm, *.MYD,*.MYI files has the
following size:
du -ks /seqdata/mysql/autres_bds/regen
3702719 /seqdata/mysql/autres_bds/regen ... I get the output du -k:
2098184 myregendump
this error supposed to be:
bin/perror 27
Error code 27: File too large
As you can see I have plenty of space.
Error codes below 128 come from the kernel. It's possible for applications to
return error numbers in this range too, but it's not a good idea, and mysqldump
doesn't do it. So whatever's happening here, it's being reported by the kernel.
There are two numbers:
#define EFBIG 27 /* File too large */
#define ENOSPC 28 /* No space left on device */
EFBIG refers to limitations in the size of one file; you can get it even if
there's plenty of space in the file system. ENOSPC is the other way round: you
can get it even if the file isn't at its maximum allowed size.
In the error file I have multiple times the line:
InnoDB: Error: unable to create temporary file; errno: 2
mercure{mysql}66: bin/perror 2
Error code 2: No such file or directory
But the directory exist.
I'd guess that it doesn't. Unfortunately the message doesn't tell you which
file it's trying to create. This might be worth a bug report, since it
seriously hinders you in finding out what that particular problem is.
Why does this not show up in your verbose mysqldump?
Then I tried a verbose mysqldump.
mercure{mysql}73: /seqweb/mysql/bin/mysqldump --opt --verbose regen
/seqdata/mysql/myregendump
-- Connecting to localhost...
-- Retrieving table structure for table cpgisland_Human_May2004...
-- Sending SELECT query...
-- Retrieving rows...
...
21 tables
-- Retrieving table structure for table unit_occurence_Human_May2004...
-- Sending SELECT query...
-- Retrieving rows...
/seqweb/mysql/bin/mysqldump: Got errno 27 on write This table is 1
giga data and 500mb index.
Note that mysqldump is not very efficient in its format. How big was the
output file when it failed? I'd hazard a guess at 2 GB (specifically,
2147483647 bytes). If this is the case, it's definitely a file system
limitation.
Then I tried a mysqldump of this table only:
/seqweb/mysql/bin/mysqldump --opt --verbose regen
unit_occurence_Human_May2004
and it works fine.
How can I solve this problem?
Well, you've found one workaround :-)
What file system are you using? Could this be (Sun's old) UFS?
I'm sure that Sun has file systems that aren't limited to 2 GB; you could use
one of them. They'll probably give you other advantages too.
I have looked at the previous message in the forum but could not find
anything answering my problem.
I'm relatively confident that this isn't a mysqldump problem.
On Wednesday, 5 July 2006 at 12:28:53 -0400, Michael Stassen wrote:
My first thought is that Dominik is on the right track. I get
: perror 27
OS error code 27: File too large
which suggests there is some OS limitation. Perhaps the user running
mysqldump is limited? Do you have any larger files owned by the same
user? Can that user currently create a file larger
RE: mysqldump: Got errno 27 on write. file too large
Thank you
Of course this is a bad new. Much easier to upgrade to Mysql 5 than to change
the Kernel.
uname -a
SunOS mercure 5.9 Generic_118558-04 sun4u sparc SUNW,Ultra-80
I do not have fstab but vfstab
mercure{root}171: more vfstab
#device device mount FS fsckmount mount
#to mount to fsck point typepassat boot options
#
#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1 yes -
fd - /dev/fd fd - no -
/proc - /proc proc- no -
/dev/dsk/c0t0d0s1 - - swap- no -
/dev/dsk/c0t1d0s1 - - swap- no -
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 no
-
/dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /varufs 1 no
-
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /optufs 1 yes
-
/dev/dsk/c2t5d0s0 /dev/rdsk/c2t5d0s0 /seqweb ufs 1 yes
-
/dev/dsk/c2t5d0s5 /dev/rdsk/c2t5d0s5 /oracle ufs 1 yes
-
/dev/dsk/c2t5d0s6 /dev/rdsk/c2t5d0s6 /dbsufs 1 yes
-
/dev/dsk/c1t5d0s2 /dev/rdsk/c1t5d0s2 /seqdataufs 1
yes -
terre:/opt/net - /opt/netnfs - yes bg,soft,retry=10
#terre:/opt/samba - /opt/sambanfs - yes
bg,soft,retry=10
terre:/opt/CiscoSecure - /opt/CiscoSecurenfs - yes
bg,soft,retry=10
#terre:/archives - /archives nfs - yes
bg,soft,retry=10
titan:/var/mail - /var/mail nfs - yes
actimeo=0,bg,soft,retry=10
swap- /tmptmpfs - yes -
-Message d'origine-
De : Daniel da Veiga [mailto:[EMAIL PROTECTED]
Envoyé : Friday, 07 July 2006 13:38
À : mysql@lists.mysql.com
Objet : Re: mysqldump: Got errno 27 on write. file too large
On 7/7/06, Duhaime Johanne [EMAIL PROTECTED] wrote:
Thank you to both of you.
Just a add-on, already mentionned to Michael:
My file system allows illimited files size.
I have a file of 11G on my partition.
mercure{root}120: du -kh mercure.log.jui2006
11G mercure.log.jui2006
The owner of this file is mysql (it is the log file).
Also the sysadmin was able to create files of big size with the mkfile
command with Mysql account.
I have gone througt the change history looking for the work mysqldump and I
have not seen anythng related.
So I guest my best guess is to install Mysql 5.
Sorry, but I think this isn't going to save you.
The error you mention (as Greg told you) is not a MySQL error, it is a kernel
error reported when dealing with files larger than 2GB. This is specially true
if you're using an old kernel, or old filesystem (but filesystem is not
important in this case, only if you use a really OLD fs). Your tests are no
good for this matter, as creating a file and writting it is a complete
different task. Check:
http://en.wikipedia.org/wiki/Wikipedia:Database_dump_import_problems#Got_error_27_from_table_handler
Please report your kernel version (output of uname -a) and filesystem types
(you can post your /etc/fstab file). You must use a current kernel in order to
use large files.
This may help you too:
http://cbbrowne.com/info/fs.html
Best regards
-Message d'origine-
De : Greg 'groggy' Lehey [mailto:[EMAIL PROTECTED] Envoyé : Wednesday,
05 July 2006 22:04 À : Duhaime Johanne; Michael Stassen Cc :
mysql@lists.mysql.com; Dominik Klein Objet : Re: mysqldump: Got errno
27 on write. file too large
On Wednesday, 5 July 2006 at 9:12:52 -0400, Duhaime Johanne wrote:
I have musql 4.1.7 on Solaris 9, 64 bits and I want to mysqldump a
+-4 gigas db.
...
The full directory that contains the *.frm, *.MYD,*.MYI files has
the following size:
du -ks /seqdata/mysql/autres_bds/regen
3702719 /seqdata/mysql/autres_bds/regen ... I get the output du -k:
2098184 myregendump
this error supposed to be:
bin/perror 27
Error code 27: File too large
As you can see I have plenty of space.
Error codes below 128 come from the kernel. It's possible for applications
to return error numbers in this range too, but it's not a good idea, and
mysqldump doesn't do it. So whatever's happening here, it's being reported
by the kernel.
There are two numbers:
#define EFBIG 27 /* File too large */
#define ENOSPC 28 /* No space left on device */
EFBIG refers to limitations in the size of one file; you can get it even if
there's plenty of space in the file system. ENOSPC is the other way round:
you can get it even if the file isn't at its maximum allowed size.
In the error file I have multiple times the line:
InnoDB: Error: unable to create temporary file; errno: 2
mercure{mysql}66: bin/perror 2
Error code 2: No such file
Re: mysqldump: Got errno 27 on write. file too large
On 7/7/06, Duhaime Johanne [EMAIL PROTECTED] wrote:
Thank you
Of course this is a bad new. Much easier to upgrade to Mysql 5 than to change
the Kernel.
Yeah, unfortunatelly it is...
uname -a
SunOS mercure 5.9 Generic_118558-04 sun4u sparc SUNW,Ultra-80
Not so good news, I'm not an expert in this kind of kernel (sparc),
but I guess its been a while isince you upgraded it, isnt? If I'm
wrong, please excuse my complete lack of knowledge on this systems.
I've done a quick research and it appears to fall in the problems
described at the wiki I pointed to you.
I do not have fstab but vfstab
mercure{root}171: more vfstab
#device device mount FS fsckmount mount
#to mount to fsck point typepassat boot options
#
#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1 yes -
fd - /dev/fd fd - no -
/proc - /proc proc- no -
/dev/dsk/c0t0d0s1 - - swap- no -
/dev/dsk/c0t1d0s1 - - swap- no -
/dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 no
-
/dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /varufs 1 no
-
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /optufs 1 yes
-
/dev/dsk/c2t5d0s0 /dev/rdsk/c2t5d0s0 /seqweb ufs 1 yes
-
/dev/dsk/c2t5d0s5 /dev/rdsk/c2t5d0s5 /oracle ufs 1 yes
-
/dev/dsk/c2t5d0s6 /dev/rdsk/c2t5d0s6 /dbsufs 1 yes
-
/dev/dsk/c1t5d0s2 /dev/rdsk/c1t5d0s2 /seqdataufs 1
yes -
terre:/opt/net - /opt/netnfs - yes bg,soft,retry=10
#terre:/opt/samba - /opt/sambanfs - yes
bg,soft,retry=10
terre:/opt/CiscoSecure - /opt/CiscoSecurenfs - yes
bg,soft,retry=10
#terre:/archives - /archives nfs - yes
bg,soft,retry=10
titan:/var/mail - /var/mail nfs - yes
actimeo=0,bg,soft,retry=10
swap- /tmptmpfs - yes -
As I thought, your filesystem seems OK, I keep my bet on kernel issue.
Anyone else?
-Message d'origine-
De : Daniel da Veiga [mailto:[EMAIL PROTECTED]
Envoyé : Friday, 07 July 2006 13:38
À : mysql@lists.mysql.com
Objet : Re: mysqldump: Got errno 27 on write. file too large
On 7/7/06, Duhaime Johanne [EMAIL PROTECTED] wrote:
Thank you to both of you.
Just a add-on, already mentionned to Michael:
My file system allows illimited files size.
I have a file of 11G on my partition.
mercure{root}120: du -kh mercure.log.jui2006
11G mercure.log.jui2006
The owner of this file is mysql (it is the log file).
Also the sysadmin was able to create files of big size with the mkfile
command with Mysql account.
I have gone througt the change history looking for the work mysqldump and I
have not seen anythng related.
So I guest my best guess is to install Mysql 5.
Sorry, but I think this isn't going to save you.
The error you mention (as Greg told you) is not a MySQL error, it is a kernel
error reported when dealing with files larger than 2GB. This is specially true
if you're using an old kernel, or old filesystem (but filesystem is not
important in this case, only if you use a really OLD fs). Your tests are no
good for this matter, as creating a file and writting it is a complete
different task. Check:
http://en.wikipedia.org/wiki/Wikipedia:Database_dump_import_problems#Got_error_27_from_table_handler
Please report your kernel version (output of uname -a) and filesystem types
(you can post your /etc/fstab file). You must use a current kernel in order to use large
files.
This may help you too:
http://cbbrowne.com/info/fs.html
Best regards
-Message d'origine-
De : Greg 'groggy' Lehey [mailto:[EMAIL PROTECTED] Envoyé : Wednesday,
05 July 2006 22:04 À : Duhaime Johanne; Michael Stassen Cc :
mysql@lists.mysql.com; Dominik Klein Objet : Re: mysqldump: Got errno
27 on write. file too large
On Wednesday, 5 July 2006 at 9:12:52 -0400, Duhaime Johanne wrote:
I have musql 4.1.7 on Solaris 9, 64 bits and I want to mysqldump a
+-4 gigas db.
...
The full directory that contains the *.frm, *.MYD,*.MYI files has
the following size:
du -ks /seqdata/mysql/autres_bds/regen
3702719 /seqdata/mysql/autres_bds/regen ... I get the output du -k:
2098184 myregendump
this error supposed to be:
bin/perror 27
Error code 27: File too large
As you can see I have plenty of space.
Error codes below 128 come from the kernel. It's possible for applications
to return error numbers in this range too, but it's not a good idea, and mysqldump
doesn't do it. So whatever's happening here, it's being reported by the kernel.
There are two numbers:
#define EFBIG 27 /* File too large
mysqldump: Got errno 27 on write. file too large
I have musql 4.1.7 on Solaris 9, 64 bits and I want to mysqldump a +-4
gigas db.
The dump I want to do is from a myISAM tables databank. I used to do
that dump wihtout any problem until recently while the size of the Db
double (+-2 to +-4)
The full directory that contains the *.frm, *.MYD,*.MYI files has the
following size:
du -ks /seqdata/mysql/autres_bds/regen
3702719 /seqdata/mysql/autres_bds/regen
In my.conf, tmpdir is /seqdata/mysql/tmp.
The dmp file itself is created also on /seqdata/mysql.
Space available:
mercure{root}142: df -k
Filesystemkbytesused avail capacity Mounted on
/dev/dsk/c0t0d0s07156569 6771681 31332396%/
/dev/dsk/c0t0d0s32056211 515444 147908126%/var
/dev/dsk/c2t5d0s02033839 1235855 73696963%/seqweb
/dev/dsk/c0t0d0s46120070 4997223 106164783%/opt
/dev/dsk/c1t5d0s2121640139 67202782 5322095656%/seqdata
/dev/dsk/c2t5d0s534077781 20618437 1345934461%/oracle
/dev/dsk/c2t5d0s6102749585 1677327 100044763 2%/dbs
Running the following, I eventually get an error message
mercure{mysql}53: /seqweb/mysql/bin/mysqldump --opt --flush-logs regen
/seqdata/mysql/myregendump
/seqweb/mysql/bin/mysqldump: Got errno 27 on write
and I get the output du -k: 2098184 myregendump
this error supposed to be:
bin/perror 27
Error code 27: File too large
As you can see I have plenty of space.
In the error file I have multiple times the line:
InnoDB: Error: unable to create temporary file; errno: 2
mercure{mysql}66: bin/perror 2
Error code 2: No such file or directory
But the directory exist.
Then I tried a verbose mysqldump.
mercure{mysql}73: /seqweb/mysql/bin/mysqldump --opt --verbose regen
/seqdata/mysql/myregendump
-- Connecting to localhost...
-- Retrieving table structure for table cpgisland_Human_May2004...
-- Sending SELECT query...
-- Retrieving rows...
...
21 tables
-- Retrieving table structure for table unit_occurence_Human_May2004...
-- Sending SELECT query...
-- Retrieving rows...
/seqweb/mysql/bin/mysqldump: Got errno 27 on write
This table is 1 giga data and 500mb index.
Then I tried a mysqldump of this table only:
/seqweb/mysql/bin/mysqldump --opt --verbose regen
unit_occurence_Human_May2004
and it works fine.
How can I solve this problem?
I have looked at the previous message in the forum but could not find
anything answering my problem.
Thank you in advance for any help.
Johanne Duhaime
[EMAIL PROTECTED]
tel 5556
local 1565.4, Centre de documentation
Re: mysqldump: Got errno 27 on write. file too large
How can I solve this problem? This might be a filesystem problem. Some filesystem (in certain configurations) cannot hold files larger than a particular size. Do you have any files larger than that cut dumpfile on that partition? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: mysqldump: Got errno 27 on write. file too large
Thank you for your answer.
Yes I have file larger than what mysqldump could manager. Here is an example of
this. Both files are on the same partition.
mercure{root}54: du -k mercure.log.jui2006
11948544mercure.log.jui2006
mercure{root}68: du -k myregendump
2098184 myregendump
Which stop at that size.
Which make me think that mysql is concerned. Or a tmp file but as I mention the
tmp file has plenty of space.
Best regards
Johanne
-Message d'origine-
De : Dominik Klein [mailto:[EMAIL PROTECTED]
Envoyé : Wednesday, 05 July 2006 09:30
À : mysql@lists.mysql.com
Objet : Re: mysqldump: Got errno 27 on write. file too large
How can I solve this problem?
This might be a filesystem problem. Some filesystem (in certain
configurations) cannot hold files larger than a particular size.
Do you have any files larger than that cut dumpfile on that partition?
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: mysqldump: Got errno 27 on write. file too large
Dominik Klein wrote:
This might be a filesystem problem. Some filesystems (in certain
configurations) cannot hold files larger than a particular size.
Do you have any files larger than that cut dumpfile on that partition?
Duhaime Johanne wrote:
Thank you for your answer.
Yes I have file larger than what mysqldump could manage. Here is an
example of this. Both files are on the same partition.
mercure{root}54: du -k mercure.log.jui2006
11948544mercure.log.jui2006
Umm, that's only about 1Gb, which makes it smaller than the problem file. Did
you mean to show us a different file?
mercure{root}68: du -k myregendump
2098184 myregendump
Which stop at that size.
Which make me think that mysql is concerned. Or a tmp file but as I
mention the tmp file has plenty of space.
Best regards
Johanne
My first thought is that Dominik is on the right track. I get
~: perror 27
OS error code 27: File too large
which suggests there is some OS limitation. Perhaps the user running mysqldump
is limited? Do you have any larger files owned by the same user? Can that user
currently create a file larger than that using another means?
The other possibility would be a bug. You are using version 4.1.7, which is
nearly 2 years old now (released October 2004). The current version is 4.1.20.
If you have indeed hit a bug, your best bet would be to upgrade and try
again. You should probably at least read the *long* list of bug fixes from
4.1.7 to 4.1.20 in the MySQL change history in the manual
http://dev.mysql.com/doc/refman/4.1/en/news-4-1-x.html.
Michael
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: mysqldump: Got errno 27 on write. file too large
On Wednesday, 5 July 2006 at 9:12:52 -0400, Duhaime Johanne wrote:
I have musql 4.1.7 on Solaris 9, 64 bits and I want to mysqldump a +-4
gigas db.
...
The full directory that contains the *.frm, *.MYD,*.MYI files has the
following size:
du -ks /seqdata/mysql/autres_bds/regen
3702719 /seqdata/mysql/autres_bds/regen
... I get the output du -k: 2098184 myregendump
this error supposed to be:
bin/perror 27
Error code 27: File too large
As you can see I have plenty of space.
Error codes below 128 come from the kernel. It's possible for
applications to return error numbers in this range too, but it's not a
good idea, and mysqldump doesn't do it. So whatever's happening here,
it's being reported by the kernel.
There are two numbers:
#define EFBIG 27 /* File too large */
#define ENOSPC 28 /* No space left on device */
EFBIG refers to limitations in the size of one file; you can get it
even if there's plenty of space in the file system. ENOSPC is the
other way round: you can get it even if the file isn't at its maximum
allowed size.
In the error file I have multiple times the line:
InnoDB: Error: unable to create temporary file; errno: 2
mercure{mysql}66: bin/perror 2
Error code 2: No such file or directory
But the directory exist.
I'd guess that it doesn't. Unfortunately the message doesn't tell you
which file it's trying to create. This might be worth a bug report,
since it seriously hinders you in finding out what that particular
problem is.
Why does this not show up in your verbose mysqldump?
Then I tried a verbose mysqldump.
mercure{mysql}73: /seqweb/mysql/bin/mysqldump --opt --verbose regen
/seqdata/mysql/myregendump
-- Connecting to localhost...
-- Retrieving table structure for table cpgisland_Human_May2004...
-- Sending SELECT query...
-- Retrieving rows...
...
21 tables
-- Retrieving table structure for table unit_occurence_Human_May2004...
-- Sending SELECT query...
-- Retrieving rows...
/seqweb/mysql/bin/mysqldump: Got errno 27 on write
This table is 1 giga data and 500mb index.
Note that mysqldump is not very efficient in its format. How big was
the output file when it failed? I'd hazard a guess at 2 GB
(specifically, 2147483647 bytes). If this is the case, it's
definitely a file system limitation.
Then I tried a mysqldump of this table only:
/seqweb/mysql/bin/mysqldump --opt --verbose regen
unit_occurence_Human_May2004
and it works fine.
How can I solve this problem?
Well, you've found one workaround :-)
What file system are you using? Could this be (Sun's old) UFS?
I'm sure that Sun has file systems that aren't limited to 2 GB; you
could use one of them. They'll probably give you other advantages
too.
I have looked at the previous message in the forum but could not
find anything answering my problem.
I'm relatively confident that this isn't a mysqldump problem.
On Wednesday, 5 July 2006 at 12:28:53 -0400, Michael Stassen wrote:
My first thought is that Dominik is on the right track. I get
: perror 27
OS error code 27: File too large
which suggests there is some OS limitation. Perhaps the user
running mysqldump is limited? Do you have any larger files owned by
the same user? Can that user currently create a file larger than
that using another means?
Yes, this could be a disk quota issue.
The other possibility would be a bug. You are using version 4.1.7, which
is nearly 2 years old now (released October 2004). The current version is
4.1.20. If you have indeed hit a bug, your best bet would be to upgrade
and try again. You should probably at least read the *long* list of bug
fixes from 4.1.7 to 4.1.20 in the MySQL change history in the manual
http://dev.mysql.com/doc/refman/4.1/en/news-4-1-x.html.
While it's my duty not to stand up and say it's not a mysqldump bug,
I'd be very surprised in this case--see above for reasoning.
Greg
--
Greg Lehey, Senior Software Engineer, Online Backup
MySQL AB, http://www.mysql.com/
Echunga, South Australia
Phone: +61-8-8388-8286 Mobile: +61-418-838-708
VoIP: sip:[EMAIL PROTECTED], sip:[EMAIL PROTECTED]
Diary http://www.lemis.com/grog/diary.html
Are you MySQL certified? http://www.mysql.com/certification/
pgpu1arScIahf.pgp
Description: PGP signature
