> On Thu, 8 Nov 2007 10:44:35 +0300 Al Boldi <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > > > I would suggest getting a 'tcpdump -s0' trace and seeing (with
> > > > wireshark) what is different between the various cases.
> > >
> > > Thanks Neil for looking into this. Your suggestion has a
Andrew Morton wrote:
> > > I would suggest getting a 'tcpdump -s0' trace and seeing (with
> > > wireshark) what is different between the various cases.
> >
> > Thanks Neil for looking into this. Your suggestion has already been
> > answered in a previous post, where the difference has been attribu
On Thursday November 8, [EMAIL PROTECTED] wrote:
>
> Not really a credible difference as the reported difference is between
> two *clients* and the speed of getattr vs lookup would depend on the
> *server*.
Sorry, my bad. I misread your original problem description. It would
appear to be a ser
On Wednesday November 7, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> >
> > I would suggest getting a 'tcpdump -s0' trace and seeing (with
> > wireshark) what is different between the various cases.
>
> Thanks Neil for looking into this. Your suggestion has already been answered
> in a previou
> On Wed, 7 Nov 2007 12:36:26 +0300 Al Boldi <[EMAIL PROTECTED]> wrote:
> Neil Brown wrote:
> > On Tuesday November 6, [EMAIL PROTECTED] wrote:
> > > > On Tue, 6 Nov 2007 14:28:11 +0300 Al Boldi <[EMAIL PROTECTED]> wrote:
> > > > Al Boldi wrote:
> > > > > There is a massive (3-18x) slowdown when re
Neil Brown wrote:
> On Tuesday November 6, [EMAIL PROTECTED] wrote:
> > > On Tue, 6 Nov 2007 14:28:11 +0300 Al Boldi <[EMAIL PROTECTED]> wrote:
> > > Al Boldi wrote:
> > > > There is a massive (3-18x) slowdown when re-querying a large nfs dir
> > > > (2k+ entries) using a simple ls -l.
> > > >
> >
On Tuesday November 6, [EMAIL PROTECTED] wrote:
> > On Tue, 6 Nov 2007 14:28:11 +0300 Al Boldi <[EMAIL PROTECTED]> wrote:
> > Al Boldi wrote:
> > > There is a massive (3-18x) slowdown when re-querying a large nfs dir (2k+
> > > entries) using a simple ls -l.
> > >
> > > On 2.6.23 client and server
> On Tue, 6 Nov 2007 14:28:11 +0300 Al Boldi <[EMAIL PROTECTED]> wrote:
> Al Boldi wrote:
> > There is a massive (3-18x) slowdown when re-querying a large nfs dir (2k+
> > entries) using a simple ls -l.
> >
> > On 2.6.23 client and server running userland rpc.nfs.V2:
> > first try: time -p ls -l <
Al Boldi wrote:
> There is a massive (3-18x) slowdown when re-querying a large nfs dir (2k+
> entries) using a simple ls -l.
>
> On 2.6.23 client and server running userland rpc.nfs.V2:
> first try: time -p ls -l <2k+ entry dir> in ~2.5sec
> more tries: time -p ls -l <2k+ entry dir> in ~8sec
>
>
Matthew Wilcox wrote:
> How about tcpdumping and seeing what requests are flowing across the
> wire? You might be able to figure out what's being done differently.
I think lookup is faster than getattr.
Thanks!
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Mon, Nov 05, 2007 at 07:58:38AM +0300, Al Boldi wrote:
> Any ideas?
How about tcpdumping and seeing what requests are flowing across the
wire? You might be able to figure out what's being done differently.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we u
There is a massive (3-18x) slowdown when re-querying a large nfs dir (2k+
entries) using a simple ls -l.
On 2.6.23 client and server running userland rpc.nfs.V2:
first try: time -p ls -l <2k+ entry dir> in ~2.5sec
more tries: time -p ls -l <2k+ entry dir> in ~8sec
first try: time -p ls -l <5
12 matches
Mail list logo
