From: Wakko Warner <wakko@animx.eu.org>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Strange lockup with 2.6.0
Date: Fri, 9 Jan 2004 20:06:40 -0500 [thread overview]
Message-ID: <20040109200640.B8282@animx.eu.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0401091653340.19686-100000@poirot.grange>; from Guennadi Liakhovetski on Fri, Jan 09, 2004 at 05:02:02PM +0100
> > I am constantly accessing NFS with this machine. Read and write. It was
>
> How much data at one go (max)?
I just dumped the backup I made from jaz to the nfs. I found out that some
things didn't get backed up. I did multiple backups and one file was larger
than the last (for the same filesystem).
Once I copyied to nfs (which did *NOT* crash it), I ran md5sum on both nfs
copy and jaz copy. both were exact same. then I copyied from nfs to nfs.
The size was about 350mb. (Quite surprised about the jaz drive performance
=)
> > only when I backed it up with tar. In the event it doesn't lock, tar
> > crashes w/o error/warning (over NFS).
>
> So, it locks not always?
In the above case, still was booted with init=/bin/sh and did not lockup. I
did several tar backups. Sometimes I got a segmentation fault and killed
tar, other times I got my shell killed.
I have not tried enabling TCP yet. I'm going to try a 2.4 kernel soon. (I
want to stay with 2.6 since I have a DVD+RW drive)
> > > byte or 1K or 1M? Does it lock immediately as you start the backup or
> >
> > It locks up usually at one point, but not always.
>
> Since you could backup to Jazz, looks like your filesystem is ok, NFS also
> works in principle...
As stated above, one of the filesystems did not completely backup.
> > > after some time (you could start some process in the background
> > > periodically printing some info on the terminal, like vmstat, cat
> > > /proc/interrupts, free, tcpdump on both ends to a file...) Can you try NFS
> >
> > I can do this I think. It's fun when running with init being bash. It will
> > take some time to do since I can't scroll backwards.
>
> You could also attach a serial console and direct the output there (then
> you also can scroll).
I have not retrieved this yet.
> > > 10/100mbps?
> >
> > 100 FD always.
>
> Why I am interested in your experiences is that I also have a problem
> transferring large (several M) files over NFS when the server is 2.6 and
> both ends have 100 FD. (You can see my posts this week about 2.6 NFS.) And
> in my case it TCP fixed it. But I never had hard-locks, just cp hanged in
> D, and tcpdump showed timed out reassembly on the receiving side. But I
> was reading from the server.
I have done several gig of transfers to the 2.4 server. I was burning a
bunch of data from nfs to dvd+r.
In the tests I did above, I ran dmesg several times, Not once did I see an
oops. I'm not sure, I may have a hardware problem (It's going to be
replaced soon anyway)
--
Lab tests show that use of micro$oft causes cancer in lab animals
next prev parent reply other threads:[~2004-01-10 0:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-09 14:39 Strange lockup with 2.6.0 Wakko Warner
2004-01-09 15:18 ` Guennadi Liakhovetski
2004-01-09 15:49 ` Wakko Warner
2004-01-09 16:02 ` Guennadi Liakhovetski
2004-01-09 16:45 ` Wakko Warner
2004-01-10 1:06 ` Wakko Warner [this message]
2004-01-10 3:17 ` Wakko Warner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040109200640.B8282@animx.eu.org \
--to=wakko@animx.eu.org \
--cc=g.liakhovetski@gmx.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.