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      fsck    mount   mount
#to mount       to fsck         point           type    pass    at 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      /var    ufs     1       no      
-
/dev/dsk/c0t0d0s4       /dev/rdsk/c0t0d0s4      /opt    ufs     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      /dbs    ufs     1       yes     
-
/dev/dsk/c1t5d0s2       /dev/rdsk/c1t5d0s2      /seqdata        ufs     1       
yes     -
terre:/opt/net  -       /opt/net        nfs     -       yes     bg,soft,retry=10
#terre:/opt/samba  -       /opt/samba        nfs     -       yes     
bg,soft,retry=10
terre:/opt/CiscoSecure  -       /opt/CiscoSecure        nfs     -       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    -       /tmp    tmpfs   -       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 */
> #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]
>
>


--
Daniel da Veiga
Computer Operator - RS - Brazil
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V- PS PE Y 
PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++ ------END GEEK CODE BLOCK------

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]





--
Daniel da Veiga
Computer Operator - RS - Brazil
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V-
PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++
------END GEEK CODE BLOCK------

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to