[Bug 270810] munmap does not always sync the underlying file
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 270810] munmap does not always sync the underlying file"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 16 Apr 2023 21:05:49 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810 --- Comment #6 from geoffrey@dommett.com --- The smallest test program that I have replicated this with is below. When run on a linux machine the problem does not occur, when writing to the nfs server running bsd. When run on a bsd machine, the problem seems to occur if the number of instances run is sufficient that the machine has insufficient ram that it must page between the files and the in memory copy to complete the operation. When running 50 instances is enough on the machine in front of me with 8gb of ram about 30% of them are corrupt at the end. It does not occur running just a few instances. Running 50 instances of this test on a bsd machine with 96Gb ram, 1 of them is corrupt. This same machine exhibits a lot of corruption when 300+ Gb of files are mapped. I think all times I have encountered this have been when the total files mapped exceed the physical ram of the machine. leaving in or commenting out the msync, fsync and ftruncate at the end does not stop the file corruption. #include <stdio.h> #include <sys/mman.h> #include <sys/stat.h> #include <sys/types.h> #include <fcntl.h> #include <unistd.h> int main (int argv , char** argc ) { int fl=open(argc[1] , O_RDWR | O_CREAT , 0644 ) ; lseek(fl,1000000000 , SEEK_SET); write(fl, "", 1); int * ttv = (int*) mmap(0,100000000 , PROT_WRITE | PROT_READ ,MAP_SHARED, fl , 0) ; for (int j=0 ; j<10 ; j++) { for (int ii = j ; ii<100000000/4 ; ii+=10 ) ttv[ii]=ii ; } //msync(ttv , 10000000000, MS_SYNC ) ; //fsync(fl) ; //ftruncate(fl ,9000000000) ; close(fl) ; } -- You are receiving this mail because: You are the assignee for the bug.