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

[Yar Tikhiy]

On Thu, May 25, 2006 at 11:23:43PM +0400, 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

Gee, it looks like my message :-)

I've just found that it should be /boot/loader that is responsible
for overwriting files with nextboot.conf contents, no kernel involved.
I've filed details in PR bin/98005.

-- 
Yar