Hi,
I modified the linux NFS client, kernel 2.4.5 and 2.4.6-pre7, to send
an extra SETATTR, with special values, within nfs_open and nfs_release
so that I would be able to track file open and close. For the server I
am using a slightly modified linux user level nfs server.
What I noticed is that after this change I get:
RPC: rpciod waiting on sync task!
coming from the kernel under heavy read load, especially with
larger chunks of data 8k, 16, and 64k.
The code introduced into nfs_open and nfs_release is:
memset( &fattr, 0, sizeof(struct nfs_fattr) );
memset( &attr, 0, sizeof(struct iattr) );
attr.ia_valid = ATTR_MODE | ATTR_UID | ATTR_GID | ATTR_SIZE;
attr.ia_mode = inode->i_mode;
attr.ia_uid = -10;
attr.ia_gid = -10;
attr.ia_size = -10;
attr.ia_atime = -1;
attr.ia_mtime = -1;
attr.ia_ctime = -1;
attr.ia_attr_flags = -1;
error = NFS_PROTO(inode)->setattr(inode, &fattr, &attr);
if ( error ) {
printk( "nfs_network_openclose: error=%d\n", error );
}
Does anybody see any problems with this code? The unmodified nfs client
works fine with the unmodified nfs server.
Thanks
ttyl
Dima
--
Dima Brodsky [email protected]
http://www.cs.ubc.ca/~dima
201-2366 Main Mall (604) 822-6179 (Office)
Department of Computer Science (604) 822-2895 (DSG Lab)
University of British Columbia, Canada (604) 822-5485 (FAX)
Computers are like Old Testament gods; lots of rules and no mercy.
(Joseph Campbell)
>>>>> " " == Dima Brodsky <[email protected]> writes:
> Hi, I modified the linux NFS client, kernel 2.4.5 and
> 2.4.6-pre7, to send an extra SETATTR, with special values,
> within nfs_open and nfs_release so that I would be able to
> track file open and close. For the server I am using a
> slightly modified linux user level nfs server.
> What I noticed is that after this change I get:
> RPC: rpciod waiting on sync task!
That probably means that you've put this setattr code somewhere in the
rpciod read,write or delete callbacks.
You should never mix asynchronous and synchronous calls as this can
cause the rpciod task to deadlock by waiting on itself...
Cheers,
Trond