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).
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! :)
Andrea
-
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/
This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:15 EST