This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
ripe.db.in.cl.* get large ....
- Previous message (by thread): ripe.db.in.cl.* get large ....
- Next message (by thread): ripe.db.in.cl.* get large ....
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Arnold Nipper
nipper at xlink.net
Sat Sep 23 08:16:03 CEST 1995
Curtis Villamizar wrote: > > > In message <9509211015.AA28595 at ncc.ripe.net>, Geert Jan de Groot writes: > > On Thu, 21 Sep 1995 00:01:31 +0200 (MET DST) Arnold Nipper wrote: > > > 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. > > 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 at 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
- Previous message (by thread): ripe.db.in.cl.* get large ....
- Next message (by thread): ripe.db.in.cl.* get large ....
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]