[lkml]   [2002]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS problem after 2.4.19-pre3, not solved
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 !!!


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! :)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.083 / U:30.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site