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 PROTECTED], sip:[EMAIL PROTECTED]
Diary http://www.lemis.com/grog/diary.html
Are you MySQL certified? http://www.mysql.com/certification/
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
