Next Steps: CVS Import Bug - Please Respond

[Oproescu Bogdan (KTXA 3)]

   Hello Todd, 

   Thanks for your messages. As this is the latest ( & hopefully greatest ), 
   I will reply to this message. My answers are the following: 

   1. Example of .jar file sizes: 

   1.1. On Central CVS Server: ( CVS Version 1.11.19 ) 

cvsadmin@su64sr20% pwd
/rep/fnagl/FNDB/agl/FNDB
cvsadmin@su64sr20% ls -l
total 1042730
-r--r--r--   1 f457276  fnagl      25083 Aug 10 14:47 build.xml,v
drwxrwsr-x   9 f457276  fnagl       1024 Aug 10 06:37 cfg
-r--r--r--   1 f457276  fnagl      19253 Aug 10 14:47 component.xml,v
-r--r--r--   1 f457276  fnagl    345754237 Aug 10 14:47 FNDB.jar,v
-r--r--r--   1 f457276  fnagl    115706783 Aug 10 14:47 FNDB_src.jar,v
-r--r--r--   1 f457276  fnagl    66292136 Aug 10 14:47 FNDB_T.jar,v
-r--r--r--   1 f457276  fnagl    5943584 Aug 10 14:47 FNDB_T_src.jar,v
-r--r--r--   1 f457276  fnagl     107789 Aug 10 14:47 qmbbuildstatus.xml,v
cvsadmin@su64sr20% 

   1.2. On Local Windows XP Client: ( CVS Version 1.11.19 ) 

C:\Temp\FNDB\agl\FNDB>dir
 Volume in drive C is FIT
 Volume Serial Number is 5C7F-7C2D

 Directory of C:\Temp\FNDB\agl\FNDB

09.08.2005  10:41    <DIR>          .
09.08.2005  10:41    <DIR>          ..
22.06.2005  23:41             4'729 build.xml
09.08.2005  10:41    <DIR>          cfg
15.06.2005  12:45               249 component.xml
23.03.2005  10:07         5'926'846 FNDB.jar
27.07.2005  08:42         2'487'498 FNDB_src.jar
27.07.2005  08:42         1'518'333 FNDB_T.jar
27.07.2005  08:42           737'882 FNDB_T_src.jar
27.07.2005  08:42             1'429 qmbbuildstatus.xml
               7 File(s)     10'676'966 bytes
               3 Dir(s)  12'662'513'664 bytes free

C:\Temp\FNDB\agl\FNDB>
   
   Here, the problem .jar file is FNDB_T.jar,v, and its size on the 
   Central CVS Server is as above 66,292,136 Bytes, whereas on XP 
   the size of the FNDB_T.jar file is 1,518,333 Bytes. 

   2. Here is a snapshot of the Used and Available Disk Space on our CVS 
Central Server: 

cvsadmin@su64sr20% df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/vx/dsk/rootvol  4133838  910422 3182078    23%    /
/proc                      0       0       0     0%    /proc
fd                         0       0       0     0%    /dev/fd
mnttab                     0       0       0     0%    /etc/mnttab
/dev/vx/dsk/var      8263373 1116377 7064363    14%    /var
swap                 20114904      24 20114880     1%    /var/run
swap                 20271608  156728 20114880     1%    /tmp
/dev/vx/dsk/cs       48798880  730311 47580581     2%    /cs
/dev/vx/dsk/home     1021735  893744   66687    94%    /export/home
/dev/vx/dsk/fildg/repvol
                     209715200 85542922 116411715    43%    /cs/rep
cvsadmin@su64sr20%   
   
   3. Does this information above help you clarify this issue at all? 
   But I have another suggestion: I think this problem is due solely 
   because these .jar files are large and that by doing parallel 
   cvs imports, they are becoming corrupted. Maybe you can make some 
   test cases on your side and experiment this import-import and 
   import-tag cases in parallel with some large .jar files, and you 
   should be able to reconstruct the error. I can reproduce this error 
   at any time, so I don't think it will be a problem on your side either. 
   Maybe this will help us solve this cvs bug faster. 

   Cheers, Bogdan 

   Bogdan Oproescu 

   CREDIT SUISSE FINANCIAL SERVICES
   Technology & Services
   Advanced Middleware &
   Development Environments KTXA 3 
   Postfach 600
   CH-8070 Zürich
   Tel.: +41 1 334 6846
   Fax.:+41 1 332 8024
   E-Mail: bogdan.oproescu@credit-suisse.ch
   Internet: http://www.credit-suisse.ch/de/index.html

-----Original Message-----
From: tdennist@ssa.crane.navy.mil [mailto:tdennist@ssa.crane.navy.mil] On 
Behalf Of Todd Denniston
Sent: Wednesday, August 10, 2005 3:43 PM
To: Oproescu Bogdan (KTXA 3)
Cc: 'bug-cvs@nongnu.org'
Subject: Re: Next Steps: CVS Import Bug - Please Respond

"Oproescu Bogdan (KTXA 3)" wrote:
> 
>    Hello Bernd,
> 
>    Thanks for your message below. Here are my answers to your questions:
> 
>    1. The failures seem to move around at random, but the pattern seems
>    always to be large .jar files, causing time overlap between 2 or more
>    parallel CVS Clients into the SAME Module and Repository pair on our
>    CVS Central Server. Same is true for the import-tag pair on 2 or more
>    parallel CVS Clients, but I think this is another manifestation of the
>    first problem, namely that the "cvs import" is not atomic, so 2 or more
>    parallel CVS Clients will produce this issue, over and over again.
> 
>    2. Our CVS Central Server is Unix Solaris 8.0:
> cvsadmin@su64sr20% uname -i -m -p -r -s -v
> SunOS 5.8 Generic_117350-02 sun4u sparc SUNW,Sun-Fire-480R
> cvsadmin@su64sr20%
<SNIP>
Sorry for replying to the other message before reading this one...

Along the lines of the information from my previous email, you should be
aware that, at least with the sun machines I have used:
 solaris shares (at least part of) its tmp directory space with its virtual
memory space,
 and you may need to mod my previous limits to:
2) the source or ,v file reaches ~1/4 or ~1/6 the size of your server's temp
partition's limit.
Or
3) the source or ,v file reaches ~1/2 the full Virtual Memory size of the
server, i.e., ~1/2 of real ram + ~1/4 of swap space.
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter