https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222356
--- Comment #4 from Tijl Coosemans <[email protected]> --- (In reply to Konstantin Belousov from comment #3) It's UFS with softupdates and journaling. This test program is more like what Firefox does. It opens and unlinks a file, sets the size with ftruncate and uses mmap. There's no disk I/O that I can notice except for the final close which causes a lot of I/O. If you put munmap last the I/O happens on that call. The bigger the file the longer it takes. Surely this isn't all metadata? #include <sys/mman.h> #include <fcntl.h> #include <stdio.h> #include <string.h> #include <unistd.h> int main( void ) { int fd; size_t sz; void *base; sz = 128 * 1024 * 1024; fd = open( "nosync.data", O_RDWR | O_CREAT, 0600 ); unlink( "nosync.data" ); ftruncate( fd, sz ); base = mmap( NULL, sz, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_NOSYNC, fd, 0 ); puts( "calling memset" ); memset( base, '0', sz ); puts( "memset called" ); sleep( 5 ); puts( "calling munmap" ); munmap( base, sz ); puts( "munmap called" ); sleep( 5 ); puts( "calling close" ); close( fd ); puts( "close called" ); sleep( 5 ); return( 0 ); } I didn't really investigate the problem with your patch. I could build Firefox fine and then suddenly gmake couldn't find some targets that were clearly defined in the Makefile. Rerunning the make command a couple times always gave this same error. Rebooting with the old kernel fixed it. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-gecko To unsubscribe, send any mail to "[email protected]"
