Re: weird bugs with mmap-ing via NFS

	[Moved from -current to -stable]

вівторок 21 березень 2006 16:23, Matthew Dillon Ви написали:
>     You might be doing just writes to the mmap()'d memory, but the system
>     doesn't know that.

Actually, it does. The program tells it, that I don't care to read, what's 
currently there, by specifying the PROT_READ flag only.

>     The moment you touch any mmap()'d page, reading or writing, the system
>     has to fault it in, which means it has to read it and load valid data
>     into the page.

Sounds like a missed optimization opportunity :-(

> :When I mount with large read and write sizes:
> :
> :       mount_nfs -r 65536 -w 65536 -U -ointr pandora:/backup /backup
> :
> :it changes -- for the worse. Short time into it -- the file stops growing
> :according to the `ls -sl' run on the NFS server (pandora) at exactly 3200
> : FS blocks (the FS was created with `-b 65536 -f 8129').
> :
> :At the same time, according to `systat -if' on both client and server, the
> :   client continues to send (and the server continues to receive) about
> : 30Mb of some (?) data per second.

>     It kinda sounds like the buffer cache is getting blown out, but not
>     having seen the program I can't really analyze it.

See http://aldan.algebra.com/~mi/mzip.c

>     It will always be more efficient to write to a file using write() then
>     using mmap()

I understand, that write() is much better optimized at the moment, but the 
mmap interface carries some advantages, which may allow future OSes to 
optimize their ways. The application can hint at its planned usage of the 
data via madvise, for example.

Unfortunately, my problem, so far, is with it not writing _at all_...

>     and it will always be far, far more efficient to write to an NFS file in
>     nfs block-sized chunks rather then in smaller chunks 
>     due to the way the buffer cache works.

Yes, this is an example of how a good implemented mmap can be better than 
write. Without explicit writes by the application and without doubling the 
memory requirements, the data can be written in the most optimal way.

Thanks for your help. Yours,

	-mi