Message-ID: <EE83E551E08D1D43AD52D50B9F511092E11499@ntserver2>
From: Gregory Giguashvili <Gregoryg@ParadigmGeo.com>
To: "Linux Kernel (E-mail)" <linux-kernel@vger.kernel.org>
Cc: Alex Shaltiel <shalt@ParadigmGeo.com>, Oleg Meshbey <oleg@ParadigmGeo.com>
Subject: Memory mapped files on NFS mounted drives
Date: Mon, 22 Jul 2002 18:28:34 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C2319C.D2D8ADB0"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3900
Lines: 129

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C2319C.D2D8ADB0
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

OS/Kernel checked:
===============
RH 7.2 (kernel 2.4.7-10) and RH 7.3 (kernel 2.4.18-3) (I haven't checked the
others).

Problem description:
===============
I attempt to read/write memory mapped file from two Linux machines, which
resides on NFS mounted drive. The file gets corrupted since the changes made
on one machine aren't immediately available on the other. The sample program
is attached to this e-mail - simply run and play with it on NFS mounted
drive to make sure there is some inconsistency.
The problematic API set includes (mmap, munmap and msync system calls).

The original code uses NFS locking to assure file consistency, but the
example misses this part to simplicity (locking is simulated by the user).
The same code works on a variety of other operating systems, but fails to
work between two Linux or Linux/Other OS machines.

Known workarounds/patches:
======================
I decided to give up on the performance issue and even tried to remap the
whole file before every attempt to read/write the mapped file. Surprisingly,
even this extreme measure didn't help (the code is commented out using
preprocessor directives in the sample program).
I couldn't find any patch, which specifically fixes this problem, though I
have seen some patches related to msync, which I don't think to be relevant
(Am I wrong?).


I'm sure that someone has come across this problem and I sure hope there is
some workaround/patch available. 
Any help will be greatly appreciated.

Thanks in advance.
Giga

 <<mmap.cc>> 

------_=_NextPart_000_01C2319C.D2D8ADB0
Content-Type: application/octet-stream;
	name="mmap.cc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="mmap.cc"

#include <stdio.h>=0A=
#include <unistd.h>=0A=
#include <sys/mman.h>=0A=
#include <string.h>=0A=
#include <sys/types.h>=0A=
#include <sys/stat.h>=0A=
#include <fcntl.h>=0A=
=0A=
int main (int argc, char* argv []) =0A=
{=0A=
    char buffer [BUFSIZ];=0A=
    char* pMap;=0A=
=0A=
    int fd =3D open ("MAPPED.FILE", O_CREAT | O_RDWR | O_SYNC, =
0666);=0A=
    if (fd =3D=3D -1) {=0A=
	perror ("open");=0A=
	return -1;=0A=
    }=0A=
=0A=
    write (fd, "\0", 1);=0A=
    if (lseek (fd, BUFSIZ - 1, SEEK_SET) !=3D BUFSIZ - 1) {=0A=
	perror ("lseek");=0A=
	return -1;=0A=
    }=0A=
    write (fd, "\0", 1);=0A=
=0A=
    pMap =3D (char*) mmap (NULL, BUFSIZ, PROT_READ | PROT_WRITE, =0A=
			 MAP_SHARED, fd, 0);=0A=
    if ((size_t) pMap =3D=3D -1) {=0A=
	perror ("mmap");=0A=
	return -1;=0A=
    }=0A=
    =0A=
    while (1) {=0A=
	fprintf (stderr, "<Press ENTER to read> OR <Enter string to write> $ =
");=0A=
	fgets (buffer, sizeof (buffer) - 1, stdin);=0A=
=0A=
#if 0=0A=
	if (munmap (pMap, BUFSIZ)) {=0A=
	    perror ("munmap");=0A=
	    return -1;=0A=
	}=0A=
	pMap =3D (char*) mmap (NULL, BUFSIZ, PROT_READ | PROT_WRITE, =0A=
				   MAP_SHARED, fd, 0);=0A=
	if ((size_t) pMap =3D=3D -1) {=0A=
	    perror ("mmap");=0A=
	    return -1;=0A=
	}=0A=
#endif=0A=
=0A=
	if (buffer [0] =3D=3D '\n') {=0A=
	    fprintf (stderr, "Mapped file contents: %s\n", pMap);=0A=
	} else {=0A=
	    strncpy (pMap, buffer, strlen (buffer) - 1);=0A=
	    fprintf (stderr, "Written to mapped file: %s\n", pMap);=0A=
	}=0A=
=0A=
	if (msync (pMap, BUFSIZ, MS_SYNC | MS_INVALIDATE)) {=0A=
	    perror ("msync");=0A=
	    return -1;=0A=
	}=0A=
    }=0A=
=0A=
    return 0;=0A=
}=0A=

------_=_NextPart_000_01C2319C.D2D8ADB0--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/