..and the client is a RHEL 4 linux revision... (sorry for any confusion)
On 5/5/06, Joe Little <jmlittle at gmail.com> wrote: > Well, I used the dtrace script used here. The NFS implementation > (server) is Solaris 11 B38, and the client and the RHEL linux > revision, which doesn't have this problem going through other > SAN-based NAS (NetApp, EMC, etc.. even iSCSI). I previously setup a > Linux box as an iscsi initiator, XFS, and Linux's less than stellar > kNFS server revision, and did not see this interaction. Thus, if there > are any thread issues, its likely on Solaris' end or there is > particularly bad interaction with linux clients if and only if the > solaris backend is iSCSI. That latter doesn't make sense. > > > On 5/5/06, Bart Smaalders <bart.smaalders at sun.com> wrote: > > Joe Little wrote: > > > Perhaps I'm finding bugs in the iscsi initiator. > > > > > > I can give the full dtrace reports (should I attach them?) but for now > > > I'll give the three top segments. I did a mixed directory of only 1000 > > > items of around 3GB as a first test. The NFS->UFS test and the > > > NFS->ZFS (local) were relatively fast, but the NFS->ZFS (over iscsi) > > > was dog slow vs what that ZFS/iscsi link normally does. > > > > > > > Could it be that your NFS implementation is single threaded on synch. > > operations? > > > > In other words, the NFS implementation (or benchmark) is forcing lots > > of synchronous IO operations that are single threaded. If you're always > > waiting for data to end up on the platter before issuing the next IO > > request, this would kill performance. > > > > Perhaps a DTrace script to check workload concurrency is in order... > > > > - Bart > > > > > > > > -- > > Bart Smaalders Solaris Kernel Performance > > barts at cyber.eng.sun.com http://blogs.sun.com/barts > > >
