Nobodies. That is correct behaviour in fact. The host box wont let you
overwrite a binary image that it is running. NFS doesnt know a handy
matching error code so uses the generic "I/O error" report
> become free), I get queue_glue lacking the memory to reassemble fragments,
> escalating to NFS timeouts, whenever I do something (e.g. xv) which is both
> memory intensive and net-using. 2.1.65 with the keep-big-free-areas patch
> worked okay, but even by 2.1.76 I still get this behavior... Is anyone
> addressing it? Or am I just strange, in need of a huger
> /proc/sys/vm/freepages, or in need of >32M of RAM?
These are caused by weaknesses in the VM layer and the SLAB memory allocators
on a small machine or under some load patterns they make NFS unusable in 2.1.x
Various people are doing VM things and this obviously has to be cured by
2.2.
> can write it bottom-up, except I haven't found yet how to determine the
> address of the memory management structures for a page given its physical
> address (i.e. find the buddy of a free page so I can try to free it...).
Not only that - but there may be several of them, and they may be in use.
The buddy system is very bad for fragmentation and abominably bad for
cache performance. SLAB fixes that for a lot of the smaller kernel allocators
but it doesnt solve the whole problem.
Alan