On Wed, 8 Dec 1999, Matthew Dillon wrote:
Operationally, the syncer will not sync the file while any mmap()'s
exist with that flag set. Once such flagged maps go away, the syncer
will be able to sync the file (if it still exists).
Comments are welcome.
I assume that this
:I assume that this flag would require write permission to the file, to
:prevent bad security implications?
:
:--
: Ben Rosengart
You can set the flag without write permission but it will not do anything
in that case. The only way to get a page marked such that the syncer
doesn't
On Wed, 8 Dec 1999, Matthew Dillon wrote:
I would like to add a new MAP_ flag to mmap() prior to the 4.x freeze.
The purpose of the flag is to prevent the syncer from syncing the
file underlying the map. The VM system will still page to the file as
needed and, of course,
:I'd like to see this happen, go for it! :)
:
:Don't forget how getnewbuf refils the buffers though, it will need to
:somehow to communicate to the syncer to disregard MAP_NOSYNC during a
:shortage... ? :)
:
:-Alfred
No, I don't bother with that. If there is a filesystem buffer associated
:
:
:I think that you imply explicit msync() calls still flush data to disk. Is
:that the case?
:
:Jason Young
:accessUS Chief Network Engineer
msync never guarenteed the flushing of data to disk, it simply guarentees
synchronization with the buffer cache. FreeBSD, however, uses a
I think that you imply explicit msync() calls still flush data to disk. Is
that the case?
Jason Young
accessUS Chief Network Engineer
On Wed, 8 Dec 1999, Matthew Dillon wrote:
:I'd like to see this happen, go for it! :)
:
:Don't forget how getnewbuf refils the buffers though, it will need
good flag. If you look at my old mnfs stuff you can see our solution : we
ignored sync :-)
This is a good move.
ron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
7 matches
Mail list logo
