Thanks. I'm playing with it now, trying to get the most succinct test. This is one thing that bothers me: Regardless of the backend, it appears that a delete of a large tree (say the linux kernel) over NFS takes forever, but its immediate when doing so locally. Is delete over NFS really take such a different code path?
On 5/5/06, Lisa Week <Lisa.Week at sun.com> wrote: > These may help: > > http://opensolaris.org/os/community/dtrace/scripts/ > Check out iosnoop.d > > http://www.solarisinternals.com/si/dtrace/index.php > Check out iotrace.d > > - Lisa > > Joe Little wrote On 05/05/06 18:59,: > > > Are there known i/o or iscsi dtrace scripts available? > > > > On 5/5/06, Spencer Shepler <spencer.shepler at sun.com> wrote: > > > >> On Fri, Joe Little wrote: > >> > On 5/5/06, Eric Schrock <eric.schrock at sun.com> wrote: > >> > >On Fri, May 05, 2006 at 03:46:08PM -0700, Joe Little wrote: > >> > >> Thanks for the tip. In the local case, I could send to the > >> > >> iSCSI-backed ZFS RAIDZ at even faster rates, with a total > >> elapsed time > >> > >> of 50seconds (17 seconds better than UFS). However, I didn't > >> even both > >> > >> finishing the NFS client test, since it was taking a few seconds > >> > >> between multiple 27K files. So, it didn't help NFS at all. I'm > >> > >> wondering if there is something on the NFS end that needs changing, > >> > >> no? > >> > > > >> > >Keep in mind that turning off this flag may corrupt on-disk state > >> in the > >> > >event of power loss, etc. What was the delta in the local case? 17 > >> > >seconds better than UFS, but percentage wise how much faster than the > >> > >original? > >> > > > >> > > >> > I believe it was only about 5-10% faster. I don't have the time > >> > results off hand, just some dtrace latency reports. > >> > > >> > >NFS has the property that it does an enormous amount of synchronous > >> > >activity, which can tickle interesting pathologies. But it's strange > >> > >that it didn't help NFS that much. > >> > > >> > Should I also mount via async.. would this be honored on the Solaris > >> > end? The other option mentioned with similar caveats was nocto. I just > >> > tried with both, and the observed transfer rate was about 1.4k/s. It > >> > was painful deleting the 3G directory via NFS, with about 100k/s > >> > deletion rate on these 1000 files. Of course, When I went locally the > >> > delete was instantaneous. > >> > >> I wouldn't change any of the options at the client. The issue > >> is at the server side and none of the other combinations that you > >> originally pointed out have this problem, right? Mount options at the > >> client will just muddy the waters. > >> > >> We need to understand if/what the NFS/ZFS/iscsi interaction is and why > >> it is so much worse. As Eric mentioned, there may be some interesting > >> pathologies at play here and we need to understand what they are so > >> they can be addressed. > >> > >> My suggestion is additional dtrace data collection but I don't have > >> a specific suggestion as to how/what to track next. > >> Because of the significant additional latency, I would be looking for > >> big increases in the number of I/Os being generated to the iscsi backend > >> as compared to the local attached case. I would also look for > >> some type of serialization of I/Os that is occurring with iscsi vs. > >> the local attach. > >> > >> Spencer > >> > > _______________________________________________ > > nfs-discuss mailing list > > nfs-discuss at opensolaris.org > >
