Even 1G seems not to be enough. Any hints???? docldbm - inserted 41300 /db: write failed, file system is full dbm store returned -1, errno 28, key "3267231744/16" at /home/xladm/lib/cldb.pl line 134, <db> line 382118. docldbm - inserted 41400 docldbm - inserted 41500 .... docldbm - inserted 42100 xlink100# head -2 ripe.db.in # # 950920 04:00:01 xlink100# wc ripe.db.in 382118 980308 7111286 ripe.db.in xlink100# df . Filesystem kbytes used avail capacity Mounted on /dev/sd2h 1016506 1016467 0 111% /db xlink100# \rm ripe.db.in.cl.* xlink100# df . Filesystem kbytes used avail capacity Mounted on /dev/sd2h 1016506 32339 882517 4% /db Regards, Arnold -- Arnold Nipper / email: nipper@xlink.net NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich Xlink /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ D-76131 Karlsruhe, Germany
Even 1G seems not to be enough. Any hints???? /db: write failed, file system is full dbm store returned -1, errno 28, key "3267231744/16" at /home/xladm/lib/cldb.
On Thu, 21 Sep 1995 00:01:31 +0200 (MET DST) Arnold Nipper wrote: pl line 134, <db> line 382118. Hi Arnold, So far, we are unable to reproduce this problem at the RIPE NCC. We have: $ ls -ls *in.cl* 96 -rw-r--r-- 1 auto-dbm 475136 Sep 20 18:18 ripe.db.in.cl.dir 6896 -rw-r--r-- 1 auto-dbm 1728316416 Sep 21 11:02 ripe.db.in.cl.pag Note that while the 'size' of the file is large, it only takes 7MB of real disk space (the UNIX 'hole file' feature), not anything near what you are reporting. $ df . Filesystem kbytes used avail capacity Mounted on dbase.ripe.net:/export/nccfs18/Dbase 759381 471792 211651 69% /tmp_mnt/ncc/dbase These are the log files since eternety, mirrors + indexes of the other databases, testdatabases and other gunk. In order for us to be able to reproduce this problem, we would like people that encounter it send reports to ripe-dbm@ripe.net with the following information: 1. ls -ls of the files involved 2. Do you 'clean' the database frequently? 3. perl -v? 4. ls -ls of the bin directory of the database 5. egrep $Id of the same bin directory 6. You OS & version number, patches? 7. If you know, what dbm you are using with perl Help save the world & send us reports. Hope this helps, Geert Jan & David
In message <9509211015.AA28595@ncc.ripe.net>, Geert Jan de Groot writes:
Even 1G seems not to be enough. Any hints???? /db: write failed, file system is full dbm store returned -1, errno 28, key "3267231744/16" at /home/xladm/lib/cld b.
On Thu, 21 Sep 1995 00:01:31 +0200 (MET DST) Arnold Nipper wrote: pl line 134, <db> line 382118.
Hi Arnold,
So far, we are unable to reproduce this problem at the RIPE NCC. We have: $ ls -ls *in.cl* 96 -rw-r--r-- 1 auto-dbm 475136 Sep 20 18:18 ripe.db.in.cl.dir 6896 -rw-r--r-- 1 auto-dbm 1728316416 Sep 21 11:02 ripe.db.in.cl.pag
Note that while the 'size' of the file is large, it only takes 7MB of real disk space (the UNIX 'hole file' feature), not anything near what you are reporting.
$ df . Filesystem kbytes used avail capacity Mounted on dbase.ripe.net:/export/nccfs18/Dbase 759381 471792 211651 69% /tmp_mnt/ncc/dbase These are the log files since eternety, mirrors + indexes of the other databases, testdatabases and other gunk.
In order for us to be able to reproduce this problem, we would like people that encounter it send reports to ripe-dbm@ripe.net with the following information:
1. ls -ls of the files involved 2. Do you 'clean' the database frequently? 3. perl -v? 4. ls -ls of the bin directory of the database 5. egrep $Id of the same bin directory 6. You OS & version number, patches? 7. If you know, what dbm you are using with perl Help save the world & send us reports.
Hope this helps,
Geert Jan & David
This is almost certain to be due to the version of *DBM that you have linked in with perl. Try linking perl with the BSD DB library, using the NDBM emulation. Curtis
Curtis Villamizar wrote:
In message <9509211015.AA28595@ncc.ripe.net>, Geert Jan de Groot writes:
Even 1G seems not to be enough. Any hints???? /db: write failed, file system is full dbm store returned -1, errno 28, key "3267231744/16" at /home/xladm/lib/cld b.
On Thu, 21 Sep 1995 00:01:31 +0200 (MET DST) Arnold Nipper wrote: pl line 134, <db> line 382118.
Hi Arnold,
So far, we are unable to reproduce this problem at the RIPE NCC. We have: $ ls -ls *in.cl* 96 -rw-r--r-- 1 auto-dbm 475136 Sep 20 18:18 ripe.db.in.cl.dir 6896 -rw-r--r-- 1 auto-dbm 1728316416 Sep 21 11:02 ripe.db.in.cl.pag
Note that while the 'size' of the file is large, it only takes 7MB of real disk space (the UNIX 'hole file' feature), not anything near what you are reporting.
$ df . Filesystem kbytes used avail capacity Mounted on dbase.ripe.net:/export/nccfs18/Dbase 759381 471792 211651 69% /tmp_mnt/ncc/dbase These are the log files since eternety, mirrors + indexes of the other databases, testdatabases and other gunk.
In order for us to be able to reproduce this problem, we would like people that encounter it send reports to ripe-dbm@ripe.net with the following information:
1. ls -ls of the files involved 2. Do you 'clean' the database frequently? 3. perl -v? 4. ls -ls of the bin directory of the database 5. egrep $Id of the same bin directory 6. You OS & version number, patches? 7. If you know, what dbm you are using with perl Help save the world & send us reports.
Hope this helps,
Geert Jan & David
This is almost certain to be due to the version of *DBM that you have linked in with perl. Try linking perl with the BSD DB library, using the NDBM emulation.
I've run the same on a DPX20 which gives dbm store returned -1, errno 27, key "3267231744/16" at /home2/xladm/lib/cldb.pl line 134, <db> line 383372. dbm store returned -1, errno 27, key "3267231744/16" at /home2/xladm/lib/cldb.pl line 134, <db> line 383372. 1. -rw-r--r-- 1 xladm system 7133440 Sep 23 04:36 ripe.db.in -rw-r--r-- 1 xladm system 90112 Sep 23 07:26 ripe.db.in.cl.dir -rw-r--r-- 1 xladm system 724260864 Sep 23 07:26 ripe.db.in.cl.pag 2. Built daily from RIPE DB data 3. $RCSfile: perl.c,v $$Revision: 4.0.1.8 $$Date: 1993/02/05 19:39:30 $ Patch level: 36 4., 5. same as before 6. AIX xlink5 2 3 002033797500 7. ?? Database looks almost fine except (3267231744 = 194.190.0.0): whois -r -h whois.xlink.net -T inetnum -M 194.190.0.0/16 | grep 194.190. inetnum: 194.190.75.0 inetnum: 194.190.77.0 inetnum: 194.190.76.0 inetnum: 194.190.78.0 whois -r -h whois.ripe.net -T inetnum -M 194.190.0.0/16 | grep 194.190. inetnum: 194.190.2.0 - 194.190.3.0 inetnum: 194.190.16.0 - 194.190.17.0 inetnum: 194.190.18.0 - 194.190.19.0 inetnum: 194.190.22.0 - 194.190.23.0 inetnum: 194.190.38.0 - 194.190.39.0 inetnum: 194.190.44.0 - 194.190.45.0 inetnum: 194.190.48.0 - 194.190.49.0 inetnum: 194.190.62.0 - 194.190.63.0 inetnum: 194.190.68.0 - 194.190.69.0 inetnum: 194.190.128.0 inetnum: 194.190.1.0 inetnum: 194.190.0.0 inetnum: 194.190.4.0 inetnum: 194.190.6.0 inetnum: 194.190.8.0 inetnum: 194.190.7.0 inetnum: 194.190.5.0 inetnum: 194.190.11.0 inetnum: 194.190.10.0 inetnum: 194.190.12.0 inetnum: 194.190.14.0 inetnum: 194.190.15.0 inetnum: 194.190.13.0 inetnum: 194.190.25.0 inetnum: 194.190.24.0 inetnum: 194.190.32.0 inetnum: 194.190.20.0 inetnum: 194.190.21.0 inetnum: 194.190.34.0 inetnum: 194.190.36.0 inetnum: 194.190.33.0 inetnum: 194.190.35.0 inetnum: 194.190.37.0 inetnum: 194.190.9.0 inetnum: 194.190.41.0 inetnum: 194.190.40.0 inetnum: 194.190.42.0 inetnum: 194.190.43.0 inetnum: 194.190.46.0 inetnum: 194.190.47.0 inetnum: 194.190.51.0 inetnum: 194.190.52.0 inetnum: 194.190.50.0 inetnum: 194.190.54.0 inetnum: 194.190.53.0 inetnum: 194.190.55.0 inetnum: 194.190.60.0 inetnum: 194.190.61.0 inetnum: 194.190.59.0 inetnum: 194.190.58.0 inetnum: 194.190.129.0 inetnum: 194.190.65.0 inetnum: 194.190.64.0 inetnum: 194.190.57.0 inetnum: 194.190.56.0 inetnum: 194.190.66.0 inetnum: 194.190.67.0 inetnum: 194.190.71.0 inetnum: 194.190.70.0 inetnum: 194.190.72.0 inetnum: 194.190.74.0 inetnum: 194.190.73.0 inetnum: 194.190.75.0 inetnum: 194.190.77.0 inetnum: 194.190.76.0 inetnum: 194.190.78.0
Curtis
-- Arnold
Well, seems that we've also been hit by the problem. We are using the lattest available ripe db software, perl 4.036 with standard dbm libraries on a SunOS 4.1.3. The database is a secondary copy of the RIPE db. I will investigate a bit more on Tuesday. -- Benoit Grange NIC France E-Mail: nic@nic.fr Personnal E-Mail : Benoit.Grange@inria.fr WWW: www.nic.fr Pour verifier une installation de DNS: http://www.nic.fr/ZoneCheck
I also have this problem using 4.0.36 on Solaris (5.4). Will also debugging as soon as get a spare cycle. --Tony. Benoit Grange <Benoit.Grange@inria.fr> writes: * * Well, seems that we've also been hit by the problem. We are using the * lattest available ripe db software, perl 4.036 with standard dbm * libraries on a SunOS 4.1.3. The database is a secondary copy of the * RIPE db. * * I will investigate a bit more on Tuesday. * * -- * Benoit Grange * * NIC France E-Mail: nic@nic.fr * Personnal E-Mail : Benoit.Grange@inria.fr * WWW: www.nic.fr * * Pour verifier une installation de DNS: http://www.nic.fr/ZoneCheck
In message <"xlink100.x.822:23.08.95.06.16.08"@xlink.net>, Arnold Nipper writes :
This is almost certain to be due to the version of *DBM that you have linked in with perl. Try linking perl with the BSD DB library, using the NDBM emulation.
I've run the same on a DPX20 which gives
dbm store returned -1, errno 27, key "3267231744/16" at /home2/xladm/lib/cldb .pl line 134, <db> line 383372. dbm store returned -1, errno 27, key "3267231744/16" at /home2/xladm/lib/cldb .pl line 134, <db> line 383372.
1.
-rw-r--r-- 1 xladm system 7133440 Sep 23 04:36 ripe.db.in -rw-r--r-- 1 xladm system 90112 Sep 23 07:26 ripe.db.in.cl.dir -rw-r--r-- 1 xladm system 724260864 Sep 23 07:26 ripe.db.in.cl.pag
Berkeley DB doesn't create .pag and .dir files, but rather a .db file. Since RIPE convention is to use .db, naming gets confusing. -rw-r----- 1 curtis staff 20506746 Sep 24 23:43 ripe.db -rw-r----- 1 curtis staff 18292736 Sep 25 19:33 ripe.db.db -rw-r----- 1 curtis staff 4280320 Sep 25 19:33 ripe.db.cl.db The ripe.db.db and ripe.db.cl.db is the classfull and classless index. A total of 22 MB rather than the 700 MB you have. Remeber that the index files are just supposed to have key/offset pairs and should be smaller than the data itself as long as the storage method is not grossly inefficient. The old DBM *is* grossly inefficient and NDBM is not much better. I suggest you try relinking perl with BSD DB. This has nothing to do with which perl you are using. I'm also using perl 4.036 (4.0 pathlevel 36). I'm not sure what your error is coming from. We couldn't get any of this to run right on AIX, so if you are using AIX, that may be part of your problem. :-( Curtis
participants (5)
-
Arnold Nipper -
Benoit Grange -
Curtis Villamizar -
Geert Jan de Groot -
Tony Bates