Re: NFS problem after 2.4.19-pre3, not solved

Mario Vanoni (vanonim@dial.eunet.ch)
Sat, 11 May 2002 21:37:24 +0000


Andrea Arcangeli wrote:
>
> On Fri, May 10, 2002 at 10:27:46PM +0000, Mario Vanoni wrote:
> > Hi Trond, hi Andrea, hi All
> >
> > In production environment, since >6 months,
> > ethernet 10Mbits/s, on backup_machine
> > mount -t nfs production_machine /mnt.
> >
> > find `listing from production_machine` | \
> > cpio -pdm backup_machine
> >
> > Volume ~320MB, nearly constant.
> >
> > Medium times:
> >
> > 2.4.17-rc1aa1: 1m58s, _the_ champion !!!
> >
> > all later's, e.g.:
> >
> > 2.4.19-pre8aa2; 4m35s
> > 2.4.19-pre8-ac1: 4m00s
> > 2.4.19-pre7-rmap13a: 4m02s
> > 2.4.19-pre7: 4m35s
> > 2.4.19-pre4: 4m20s
> >
> > the last usable was:
> >
> > 2.4.19-pre3: 2m35s, _not_ a champion
> >
> > All benchmarks don't reflect
> > some production needs,
> > <2 minutes or >4 minutes
> > is a great difference !!!
>
> Yep.
>
> Some time ago you told me and Trond that 2.4.19pre8 + this below below
> patch applied on top of 2.4.19pre4 returned back to the 2.4.19pre3 2.35
> levels (the 1.58-2.35 difference could be not nfs related, and I want to
> get to 2.35 first, 2.35-4.20 is a nfs thing).
>
> ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre8aa2/00_nfs-backout-cto-1
>
> Could you double check that's the patch that makes the difference if
> applied on top of a vanilla 2.4.19pre4?
>
> I cannot figure out why such a patch applied to pre4 fixes the problem,
> while it doesn't fix the problem if applied to my tree.
>
> Maybe it wasn't that patch that fixed your problem after all, but one of
> the other nfs patches included in pre4. It would be very helpful if you
> could double check, just in case.
>
> Many thanks for the feedback! :)
>

All tests in chronological order, all today, all same volume ~320MB,
all same machines, source running 2.4.17-rc1aa1 since December 2001.
(Old values reported reflected situation in March 2002, a bit different)

2.4.19-pre3 vanilla
first time after boot 5m15s, then 1m56s 1m57s 1m56s 1m56s 1m57s
^^^^^

2.4.19-pre4 vanilla
5m20s, then 4m00s 4m01s 4m00s 4m01s 4m01a

2.4.19-pre4-nfs-backout-cto, from pr8aa2, 2 Hunks
5m13a, then 1m57s 1m58s 1m57s 1m58s 1m59s

2.4.19-pre8 vanilla
5m05s, then 4m03s 5m20s(*) 6m00(*) 4m03s 5m02(*)
(*) heavy load on source machine

2.4.19-pre8aa2
8m58s, then 3m15s 3m17s 3m16s 3m15s 3m15s
^^^^^

2.4.19-pre8aa2-nfs-backout-cto, from pre8aa2, 5 Hunks
8m43s, then 5m12s 5m17s 5m16s, enough!
^^^^^

2.4.17-rc1aa1
2m46s, then 1m57s 1m56s 1m56s 1m56s, enough?
^^^^^

As long as the NFS problem persists,
all my machines (4) continue running 2.4.17-rc1aa1!
Stable, quick, reliable ... old, but nearly perfect.

Regards and many thanks

Mario, not in lkml.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/