Trond >
Trond > > So, I guess I have two questions:
Trond > >
Trond > > + Why does Linux do the getattr following the write?
Trond >
Trond > It shouldn't unless you have turned off attribute caching.
How do I know whether it's turned on or off?
I'm using "make menuconfig": I didn't see an option to turn it off
there. I skimmed fs/attr.c and fs/nfs/inode.c, didn't see anything there
either. Is there a /proc option to toggle that switch?
Trond > If this is
Trond > not the case, please try 'echo 9 >/proc/sys/sunrpc/nfs_debug' and send
Trond > me the syslogged output.
Trond >
Let me see: I'm getting these when running the simple test:
peerless kernel: NFS: refresh_inode(6/1606202 ct=1)
peerless kernel: nfs: write(tmp/AAA(1606202), 1@1509)
peerless kernel: NFS: revalidating tmp/AAA, ino=1606202
peerless kernel: NFS: refresh_inode(6/1606202 ct=1)
peerless kernel: NFS: tmp/AAA revalidation complete
peerless kernel: NFS: nfs_updatepage(tmp/AAA 1@1509, sync=0)
peerless kernel: NFS: find_write_request(6/1606202, c02a9b88)
peerless kernel: NFS: nfs_writepage_sync(tmp/AAA 1@1509)
... and so on.
This is indicative of a lot of 1 byte write requests still, IMO.
>From my reading of the code, the msg "revalidating ..." indicates a
call to nfs_proc_getattr.
>
> Looks like nobody has updated that for a while. Linux-2.2.x has both
> read and write caching. The wsize is limited in stock linux-2.2.x to
> the page size (4k on ix86 machines), but there are currently
> experimental patches for exceeding this value.
>
Could you explain what you're saying here? Should Linux do two
4k writes for my 8,192 byte program? I don't see it doing *any*
write gathering.
To reply to the other mails:
Thierry Danis had reported that a 2.2.1-ac3 box works and that a
2.0.34 takes 14 seconds.
As for the former, maybe 2.2.1-ac3 does have a fix for this problem?
As for the latter, the actual time taken of course depends on the
speed of your network and the time it takes the NFS server to
perform the write, and whether the server "cheats" with synchronous
writes or not.
This is not the point. The point is that Linux must not send 8,192
synchronous write request.
I Lee Hetherington reported:
I get 0.06s on a Linux 2.2.2 client writing to a NetworkAppliance filer
vs. 0.05s writing to local ext2.
Again, this is entirely possible if your NetworkAppliance filer does not
do synchronous writes to disk that take 5 ms.
Jim Nance recommended:
Try applying Alan Coxes latest patch. That has a lot of NFS stuff in it.
You might have to back down to 2.2.2 to do this. I am not sure if he
has a 2.2.3 patch out yet. You can get these patches from:
ftp://ftp.linux.org.uk/pub/linux/alan/
I found this comment by Alan Cox on http://www.uk.linux.org/diary/
March 7:
Mostly I've been working on 2.2.2ac8 and merging together the
various patches that have come up and also Linus 2.2.3pre1
and pre2 changes. The NFS changes will have to wait a cut or
so. Linus fixed and cleaned up things in the dumber standard
kernel NFS I need to transport into cleaning up the write
gathering NFS code. The rest is merged.
So, I take it that the 2.2.x non-ac releases still don't do any
write gathering, but that the next ac or non-ac? release will?
- Godmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/