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 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
> with a dirty page the NOSYNC is ignored. The only time a filesystem
> buffer can be associated with a NOSYNC page is if you write(). In that
> case we allow the normal filesystem mechanisms to handle it.
>
> The tie-in is really trivial -- there is essentially one procedure which
> the object code calls to synchronize a range and it is comprised of two
> parts: Collecting dirty pages and constructing filesystem buffers
> for them, and flushing out filesystem buffers.
>
> NOSYNC simply prevents the first part from occuring for normal
> asynchronous flushes. The second part thus nevers sees the pages unless
> some other command indirectly associates them with a buffer -- like write()
> does for example.
>
> For low-memory situations we let the pagedaemon handle things. The
> pagedaemon ignores the NOSYNC flag. That is, NOSYNC space is treated
> just the same as swap-backed memory is treated - pageed only when
> necessary.
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
