Date: Thu, 14 Jun 2012 13:30:20 +0300 From: "Pavlo" <devgs@ukr.net> To: freebsd-fs@freebsd.org Subject: mmap() incoherency on hi I/O load (FS is zfs) Message-ID: <91943.1339669820.1305529125424791552@ffe15.ukr.net>
next in thread | raw e-mail | index | archive | help
There's a case when some parts of files that are mapped and then modified getting corrupted. By corrupted I mean some data is ok (one that was written using write()/pwrite()) but some looks like it never existed. Like it was some time in buffers, when several processes simultaneously (of course access was synchronised) used shared pages and reported it's existence. But after time pass they (processes) screamed that it is now lost. Only part of data written with pwrite() was there. Everything that was written via mmap() is zero. So as I said it occurs on hi I/O busyness. When in background 4+ processes do indexing of huge ammount of data. Also I want to note, it never occurred in the life of our project while we used mmap() under same I/O stress conditions when mapping was done for a whole file of just a part(header) starting from a beginning of a file. First time we used mapping of individual pages, just to save RAM, and this popped up. Solution for this problem is msync() before any munmap(). But man says: The msync() system call is usually not needed since BSD implements a coherent file system buffer cache. However, it may be used to associate dirty VM pages with file system buffers and thus cause them to be flushed to physical media sooner rather than later. Any thoughts? Thanks.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91943.1339669820.1305529125424791552>