cvs commit: src/sys/kern vfs_subr.c src/sys/nfsclient nfs_bio.c src/sys/fs/smbfs smbfs_io.c src/sys/fs/nwfs nwfs_io.c

[John Baldwin]

On Thursday 25 May 2006 15:23, Gleb Smirnoff wrote:
> On Thu, May 25, 2006 at 10:26:03AM -0400, Stephan Uphoff wrote:
> S> Gleb Smirnoff wrote:
> S> >On Thu, May 25, 2006 at 01:00:36AM +0000, Stephan Uphoff wrote:
> S> >S> ups         2006-05-25 01:00:36 UTC
> S> >S> 
> S> >S>   FreeBSD src repository
> S> >S> 
> S> >S>   Modified files:
> S> >S>     sys/kern             vfs_subr.c 
> S> >S>     sys/nfsclient        nfs_bio.c 
> S> >S>     sys/fs/smbfs         smbfs_io.c 
> S> >S>     sys/fs/nwfs          nwfs_io.c 
> S> >S>   Log:
> S> >S>   Do not set B_NOCACHE on buffers when releasing them in 
flushbuflist().
> S> >S>   If B_NOCACHE is set the pages of vm backed buffers will be 
> S> >invalidated.
> S> >S>   However clean buffers can be backed by dirty VM pages so 
invalidating 
> S> >them
> S> >S>   can lead to data loss.
> S> >S>   Add support for flush dirty page in the data invalidation function
> S> >S>   of some network file systems.
> S> >S>   
> S> >S>   This fixes data losses during vnode recycling (and other code paths
> S> >S>   using invalbuf(*,V_SAVE,*,*)) for data written using an mmaped 
file.
> S> >S>   
> S> >S>   Collaborative effort by: jhb@,mohans@,peter@,ps@,ups@
> S> >S>   Reviewed by:    tegge@
> S> >S>   MFC after:      7 days
> S> >
> S> >Can this be related to reports like this:
> S> >
> S> >http://freebsd.rambler.ru/bsdmail/freebsd-current_curr/msg00282.html
> S> >
> S> >  
> S> I believe that this is unrelated and that the sender of the message 
> S> needs to re-install screen as suggested by
> S> http://freebsd.rambler.ru/bsdmail/freebsd-current_curr/msg00283.html
> S> If I recall correctly this is required due to changes in the pty code.
> 
> I'm sorry, URLs at our mailing list search are shifting again. Probably
> my question looked dumb to you.
> 
> Here a correct URL:
> 
>   http://docs.freebsd.org/cgi/mid.cgi?20060518151232.GA37743

I don't think so.  What would happen in this case is that if you modified the 
page via mmap() it would throw the page away when it recycled the vnode and 
when you went to read from the page later it would fault it back in from the 
backing-store (i.e. disk) thus resulting in an older copy of the page from 
the last time it was flushed to disk.  It shouldn't result in one file 
getting overwritten by the contents of another, just a part of a file seeming 
to go backwards in time.

-- 
John Baldwin