Bug 22635
| Summary: | Why don't you use truncate(2) in libI77 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | kkanda <kkanda> |
| Component: | gnu | Assignee: | Ceri Davies <ceri> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.1-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->closed State Changed From-To: closed->open Closed in error. I thought it was GNU software, then realized that it isn't. Doesn't this package have a 3rd-party maintainer? State Changed From-To: open->feedback Is this problem still present in more recent releases? State Changed From-To: feedback->closed Feedback timeout (6 months or more). I will handle any feedback that this closure generates. Responsible Changed From-To: freebsd-bugs->ceri Feedback timeout (6 months or more). I will handle any feedback that this closure generates. |
LibI77 contains the truncation operation of files. Although FreeBSD has truncate(2) system call, the routine "t_runc" in endfile.c uses the copy-delete-recopy algorithm for file size truncation. This sometimes causes not only the lower performance but also the file system full. So the executables using f77(=g77) can not deal with a large sequential files which appear in large quantum chemistry, for example. "t_runc" routine seems to be used in backspace, close, endfile and rewind operations. "The Design and Implementation of the 4.4BSD" said that truncate(2) was introduced for Fortran's file operation.:-) How-To-Repeat: The following fortran code causes file system full if the available disk space is smaller than 16MB. parameter (MX=1024*1024+1) real*8 a(MX) do i=1,MX a(i)=i enddo write(1)(a(i),i=1,MX) write(6,*)"write long file on 1" rewind 1 write(6,*)"rewind 1" write(1)(a(i),i=1,MX-1) write(6,*)"write short file on 1" rewind 1 write(6,*)"rewind 1" stop end