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
