From: "Peter W. Draper"
Subject: Re: Using mmap result in data corruption
Date: Tue, 8 Mar 2005 14:41:57 +0000 (GMT)
Message-ID:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net)
by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30)
id 1D8fuW-0001Er-JH
for nfs@lists.sourceforge.net; Tue, 08 Mar 2005 06:42:12 -0800
Received: from hermes.dur.ac.uk ([129.234.4.9])
by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.41)
id 1D8fuU-0008D3-Sj
for nfs@lists.sourceforge.net; Tue, 08 Mar 2005 06:42:12 -0800
Received: from dust0.dur.ac.uk (dust0.dur.ac.uk [129.234.8.70])
by hermes.dur.ac.uk (8.11.7-20030923/8.11.7) with ESMTP id j28Efw226612
for ; Tue, 8 Mar 2005 14:41:58 GMT
Received: from starpc8.phyast.dur.ac.uk (starpc8.phyast.dur.ac.uk [129.234.184.206])
by dust0.dur.ac.uk (8.11.7+Sun/8.9.1) with ESMTP id j28EfwI05225
for ; Tue, 8 Mar 2005 14:41:58 GMT
Received: from starpc8.phyast.dur.ac.uk (localhost [127.0.0.1])
by starpc8.phyast.dur.ac.uk (8.12.8/8.12.8) with ESMTP id j28EfwRT019774
for ; Tue, 8 Mar 2005 14:41:58 GMT
Received: from localhost (pdraper@localhost)
by starpc8.phyast.dur.ac.uk (8.12.8/8.12.8/Submit) with ESMTP id j28EfvhJ019770
for ; Tue, 8 Mar 2005 14:41:58 GMT
To: nfs@lists.sourceforge.net
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net
List-Unsubscribe: ,
List-Id: Discussion of NFS under Linux development,
interoperability,
and testing.
List-Post:
List-Help:
List-Subscribe: ,
List-Archive:
> > fr den 12.11.2004 Klokka 21:06 (+0200) skreiv Miika Pekkarinen:
> >
> > I have found a reproducable issue with NFS that will lead to file
> > corruption on server. When a file is created with O_TRUNC and data is
> > copied using mmap, the new file on the server will be filled with null
> > bytes.
>
> mmap() offers absolutely NO guarantees that the file will be synced to
> disk on close. Use msync(MS_SYNC) if you want such a guarantee.
>
> Cheers,
> Trond
Hi,
like Miika I have noticed that mapped files updated over NFS are now
corrupted on the server. For me this problem looks like it arrived with
2.6.9 and is still causing problems with 2.6.11 (I'm running various
Fedora Core 2/3 clients together with various Linux and non-Linux NFS
servers, all using NFS v3).
Following Trond's advice I've changed to using an msync() call before
munmap() and that fixes the problem. However, I'd really like to avoid
the potential performance impact of using an msync(MS_SYNC) by using an
msync(MS_ASYNC) call instead, as the files I access can be mmap'd many
times, plus can be quite large, but, when I switch to msync(MS_ASYNC) the
data corruption returns (I am only interested in the correctness of the
data when my applications exit).
Surely that is incorrect behaviour? Otherwise what is the point of
msync(MS_ASYNC)?
Thanks for any help/advice on this,
Peter.
--
Dr. Peter W. Draper, Starlink Programmer, http://star-www.dur.ac.uk/~pdraper
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs