Benny Halevy <bhalevy@xxxxxxxxxxx> wrote on 06/19/2008 06:22:42 PM:
> > Well, you aren't exactly comparing apples to apples. The NFS
> > client does close-to-open semantics, meaning that it writes
> > all modified data to the server on close. The dd commands run
> > on the local file system do not. You might trying using
> > something which does an fsync before closing so that you are
> > making a closer comparison.
>
> try dd conv=fsync ...
I ran a single 'dd' with this option on /local and later on /nfs (same
filesystem nfs mounted on the same system). The script is umounting and
mounting local and nfs partitions between each 'dd'. Following are the
file sizes for 20 and 60 second runs respectively:
-rw-r--r-- 1 root root 1558056960 Jun 20 14:41 local.1
-rw-r--r-- 1 root root 671834112 Jun 20 14:41 nfs.1 (56% drop)
&
-rw-r--r-- 1 root root 3845812224 Jun 20 14:42 local.1
-rw-r--r-- 1 root root 2420342784 Jun 20 14:43 nfs.1 (37% drop)
Since I am new to NFS, I am not sure if this much degradation is expected,
or whether I need to tune something. Is there some code I can look at or
hack into to find possible locations for the performance fall? At this time
I cannot even tell whether the *possible* bug is in server or client code.
Thanks,
- KK
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
