From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31100 invoked by alias); 10 Aug 2004 15:59:53 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 31086 invoked by uid 48); 10 Aug 2004 15:59:51 -0000 Date: Tue, 10 Aug 2004 15:59:00 -0000 From: "e-frx at arnone dot de dot unifi dot it" To: gcc-bugs@gcc.gnu.org Message-ID: <20040810155943.16970.e-frx@arnone.de.unifi.it> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug fortran/16970] New: long write times via NFS X-Bugzilla-Reason: CC X-SW-Source: 2004-08/txt/msg00831.txt.bz2 List-Id: When a g77-compiled standard FORTRAN77 program writes out a file to an NFS-mounted remote partition, I/O performance dramatically drops. Same program, on the same machine, writes out the same file in a very short time when writing to a local partition. Once created on the local filesystem, the output file can be written to the NFS-mounted remote partition in a very short time using cp(1) or mv(1). This behaviour seems g77-specific, since other [proprietary... :( ] FORTRAN compilers don't have the same issue. I reproduced the behaviour with several versions of g77, among with: $ g77 -v g77 version 2.95.4 20011002 (Debian prerelease) (from FSF-g77 version 0.5.25 200 10319 (prerelease)) Driving: g77 -v -c -xf77-version /dev/null -xnone Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) /usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR_ _=95 -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(pos ix) -D_LANGUAGE_FORTRAN -traditional -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ /dev/null /dev/null GNU CPP version 2.95.4 20011002 (Debian prerelease) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc-lib/i386-linux/2.95.4/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3 /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include End of omitted list. /usr/lib/gcc-lib/i386-linux/2.95.4/f771 -fnull-version -quiet -dumpbase g77-ver sion.f -version -fversion -o /tmp/cc7Qj77b.s /dev/null GNU F77 version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled by GNU C version 2.95.4 20011002 (Debian prerelease). GNU Fortran Front End version 0.5.25 20010319 (prerelease) as -V -Qy -o /tmp/cc6Ymqqe.o /tmp/cc7Qj77b.s GNU assembler version 2.13.90.0.18 (i386-linux) using BFD version 2.13.90.0.18 2 0030121 Debian GNU/Linux ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /tmp/ccpZKWDe /tmp/cc6Ymqq e.o /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin. o -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm -lgcc -lc -lgcc /usr/lib/gcc-li b/i386-linux/2.95.4/crtend.o /usr/lib/crtn.o /tmp/ccpZKWDe __G77_LIBF77_VERSION__: 0.5.25 20010319 (prerelease) @(#)LIBF77 VERSION 19990503 __G77_LIBI77_VERSION__: 0.5.25 20010319 (prerelease) @(#) LIBI77 VERSION pjw,dmg-mods 19990503 __G77_LIBU77_VERSION__: 0.5.25 20010319 (prerelease) @(#) LIBU77 VERSION 19980709 $ g77 -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34) $ g77-3.3 -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.3/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.3 20040110 (prerelease) (Debian) I searched the web about this issue and found other people that asked about this issue on different mailing lists, but no one seems to have a solution or a work around. By digging in the g77 doc I found the ALWAYS_FLUSH dissertation, but it seems (at least to me) that this macro is no longer defined in libg2c, just to *increase* NFS I/O performance. So, I'm a bit puzzled... How to reproduce the strange behaviour: The following is done on a RedHat Enterprise Linux 3.0 machine having other RHEL3 filesystems mounted via NFS. Let's start on the local filesystem: $ df --si . Filesystem Size Used Avail Use% Mounted on /dev/cciss/c0d0p2 139GB 8.1GB 124GB 7% / $ ls mywrite.f $ cat mywrite.f program mywrite c constant definitions c """""""""""""""""""" integer n parameter (n=800000) c variable declarations c """"""""""""""""""""" integer i complex cvar c write out unformatted file c """""""""""""""""""""""""" open (unit=3,file='myout.dat',form='unformatted') close(unit=3,status='delete') open (unit=3,file='myout.dat',form='unformatted') rewind 3 cvar = (1.23e20,0.31e20) write (3) n do 10 i = 1, n cvar = cvar/1.1 write (3) cvar 10 continue close (unit=3) stop end $ g77 -static -o mywrite mywrite.f $ \time -o localtime ./mywrite $ cat localtime 3.52user 12.06system 0:15.88elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (33major+16minor)pagefaults 0swaps Now let's turn to the remote, NFS-mounted filesystem: $ df --si . Filesystem Size Used Avail Use% Mounted on 192.168.0.10:/home10b 79GB 199MB 75GB 1% /home10b $ cat /proc/mounts | grep 10b 192.168.0.10:/home10b /home10b nfs rw,v3,rsize=8192,wsize=8192,hard,udp,lock,add r=192.168.0.10 0 0 $ ls mywrite.f $ g77 -static -o mywrite mywrite.f $ \time -o nfstime ./mywrite Well, after about *one hour*, it's still running: the output file is about *one half* of its final size and still (slowly) growing... :-( I'll add the result when it's finished... Any ideas? Why do I obtain unreasonable times (two hours for a 13 Mbyte output file that can be copied to the same NFS-mounted filesystem in less than one half of a second with cp)? Any help will be much appreciated. TNX -- Summary: long write times via NFS Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: e-frx at arnone dot de dot unifi dot it CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16970