From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dan Cross <cross@math.psu.edu>
Message-Id: <200104301840.OAA19486@augusta.math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Oh....Hell.  File server problems.
In-Reply-To: <20010430073525.4977B1998A@mail.cse.psu.edu>
Cc:
Date: Mon, 30 Apr 2001 14:40:43 -0400
Topicbox-Message-UUID: 9788534c-eac9-11e9-9e20-41e7f4b1d025

In article <20010430073525.4977B1998A@mail.cse.psu.edu> you write:
>	the `patch' was just replacing something like
>
>	x = x * 512 / blocksize
>to be
>	x = x / blocksize * 512
>
>if I remember well.
>I'm the one hapilly using the ide fs and (If I'm not
>mistaken) even a >2GB disk would be a problem w/o replacing
>this thing. I don't remember exactly where I changed it (must
>be in the 9fans archives) If
>anyone needs, I'll try to find out.
>
>I think it was in the initialization code,
>but  don't remember exactly.

Thanks Nemo; I did find where you had sent the patch earlier, in
February, and I applied it to my file server and rebuilt it (adding
another 10GB IDE disk for the pseudo-worm in the process).

The patch made the change that you mention, but in the atasize()
function in devata.c.  I also changed devream() in sub.c to add a
``case Devide:'' to the switch statement on d->type.  This allowed me
to put my ``other'' filesystem on part of the IDE disk.

As far as the behavior of the file server when the worm fills up...  It
doesn't react very nicely; mine ``froze'' and appeared to be dead,
nothing would fix it except power-cycling the machine.  Charles Forsyth
mentioned that this is a known bug, which has been fixed in later
versions of the file server code, and is related to not releasing a
lock somewhere before returning from a function, or something similar.

Presumably, it could be fixed by diff'ing the current file server code
against Eric's patched file server, and incorporating changes that have
been made to the mainline

	- Dan C.