linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Jaeger <christian.jaeger@ethlife.ethz.ch>
To: linux-kernel@vger.kernel.org
Subject: Lockups with loop'ed sparse files on reiserfs?
Date: Fri, 13 Jun 2003 15:38:44 +0200	[thread overview]
Message-ID: <p04320407bb0f79fd523e@[192.168.3.11]> (raw)

Hello

I've experienced 3 lockups in the last few days, all while using 
sparse files. Could also be problems with UML, SKAS, raid5 over loop 
device, or loop devices with vfat files, but it looks like the only 
common thing is sparse files on reiserfs.

1.) kernel 2.4.20 from debian unstable (= kernel.org kernel with 
quite a few security and other patches), additionally patched with 
kernel-patch-skas 3-1 from debian. Started user-mode-linux using a 
sparse file with an ext2 filesystem on it, using tap0 networking, did 
apt-get upgrade inside this uml (which started to download (and 
already unpack?) quite a bit of stuff), halfway through the whole 
(host) system froze. Still responded to pings, but telnet $host 80 
would not show any activity from running apache. Went to the server 
room, I could change virtual terminals with Alt-<number>, but could 
not log in. Reset.

2.) same kernel:
- created 6 sparse files of 650MB each, on reiserfs filesystems (some 
of them on the same filesystem), and 2 files of 650MB on a vfat 
filesystem.
- Tied them to /dev/loop*,
- mdadm /dev/md0 -C -l 5 -n 7 -x 1 /dev/loop*
- then (while the array was building) mkreiser /dev/md0,
- mount /dev/md0 /mnt/md0
- cd /mnt/md0; netcat -l -p "$port" | multifeed '|' sh -c 'exec 
md5sum >&2' '&' cat | gpg | lzop -d | tar xf -
   (where multifeed is a C program by myself feeding the data to 
multiple processes)
   basically fetch data from tcp and untar it onto the filesystem.
After about 500MB of data has been written onto /mnt/md0, the box 
froze. Still responded to ping, but not to telnet $host 80. Could 
switch vt's, type root and enter password, but didn't get a login.

3.) kernel 2.4.18 from kernel.org (the machine ran without any 
problem (except for sporadically switching off dma on /dev/hda) with 
this kernel for about a year):
Did same thing as mentioned under 2.) (rm -rf /mnt/md0/* before 
starting the write again). This time it happened already after 
filling the md partition with about 200MB. And this time, while still 
responding to pings and being able to switch vt's, it wouldn't react 
to hitting the keys 'root'.

I'd mainly like to know if all of what I did is supported or not.

The machine is a AMD Duron 1Ghz with 256MB RAM, 3 IDE harddisks (but 
only hda and hdd involved in the above), 2 ethernet cards using 
8139too.

Christian.

             reply	other threads:[~2003-06-13 13:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-13 13:38 Christian Jaeger [this message]
2003-06-13 15:56 ` Lockups with loop'ed sparse files on reiserfs? Oleg Drokin
2003-06-13 15:59   ` Oleg Drokin
2003-06-13 18:07     ` Christian Jaeger
2003-06-13 20:22       ` Oleg Drokin
2003-06-14 23:10         ` Christian Jaeger

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='p04320407bb0f79fd523e@[192.168.3.11]' \
    --to=christian.jaeger@ethlife.ethz.ch \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).