Re: allocation of wb_args in nfs_wback_lock

Olaf Kirch (
Tue, 20 Jan 1998 17:33:24 +0100

Hi Bill,

On Tue, 20 Jan 1998 10:35:31 EST, Bill Hawes wrote:
> In reviewing the nfs writeback logic I'm a little puzzled as to why the
> allocation of the wb_args for the request is delayed until the
> nfs_wback_lock code is run.

My problem with that approach is that the args struct is simply dead
memory until the actual call happens. That has kept me from setting up
everything (including the RPC task) at the moment the request is created.
OTOH it would be critical for swapping over NFS not to block in those
operations... sigh.

The writeback code in its current form is pretty awkward anyway. The
way I implemented it you can't do any advanced stuff such as page
coalescing or even NFSv3 etc. I've completely rewritten it for NFSv3.

What has proven most useful is that the inode semapore is downed by
the VFS during any write/truncate/flush operation. This keeps the list
handling relatively sane.

> Also, it appears that after canceling a write request the request isn't
> awakened, and so a truncated page might sit for quite a while on the
> writeback list before being released. I think it would be better for
> rpc_exit to awaken the task after setting the action to null, so that
> everything would get cleaned up sooner. Does this sound reasonable to
> you?

I'm not sure. I dimly remember there was a reason why I didn't want
rpc_exit to wake up the task, but I don't recall what the problem was.
If in doubt, just try and see what happens.


Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play  |    / | \   sol.dhoop.naytheet.ah
             For my PGP public key, finger