[Ocfs2-devel] [BUG]mmap changes not not persisted

[Rusty Lynch <rusty@linux.co.intel.com>]

While try to figure out the correct way to make a 2.6 build flush out
it's buffers to disk so that all changes are not lost when the file closes,
I discovered a problem with mmap on a 2.4 build.

I created a new bugzilla bug, that explains the problem at
http://oss.oracle.com/bugzilla/show_bug.cgi?id=50

Here is a cut-n-past from my description in the bug report:

When mmap is used over write data in an existing file, the changes made are
lost once the file is closed.

This can be reproduced in a test case that will:
(SETUP) create a file of 100bytes and null out the contents of the file.
1. open the target file
2. mmap a region of the file
3. memset the pointer returned from mmap to some non-null char
4. unmap and close the file
5. hexdump the file and notice none of the changes were persisted to disk

If you were to either create a new file, or extend the existing file 
and then mmap the new region of the file, then the changes will successfully
make their way to the disk.

I am seeing this bug on version 798 of the svn repository, on a 2.4.22 based
Fedora distribution.


------- Additional Comment #1 From Rusty Lynch 2004-03-23 20:34 -------

Created an attachment (id=3)
Not so simple test case for reading and writing to a file

The following attachment is a little unit test that I am using to track down
problems with reading/writing to a file.

Using the test case, you can expose this bug by:

dd bs=1K count=1 if=/dev/urandom of=testme.bin
read_write --filename=testme.bin --size=20 --offset=0 --close --mmap

This will attempt to 
* mmap the first 20 bytes of the testme.bin file
* write a known value of random numbers
* close and reopen the file
* remap the first 20 bytes of the file
* and then read the first 20 bytes and compare it to the known value