[OpenAFS] linux 2.4, loopback bug, unkillable processes

[Blair Strang]

Hi there,

We just lost a bit of sleep due to a bug in the loopback driver which
exists in some 2.4.x kernels. The problem we were having was that kupdated 
and some fileserver processes were getting wedged in an uninterruptible
sleep. ("D" status in ps output, unkillable). 

Our setup:
----------

* Dual 1Ghz PIII's, Via MB, Symbios SCSI Controller, 2x ATLAS10K3_18_SCA disks,
  1x ST32171W disk. 
* Debian unstable
* Linux 2.4.18 + International Kernel Patch
* OpenAFS 1.2.3 compiled from source
* /vicepa on /dev/loop0 on top of normal file /store/vicepa
* /vicepb on /dev/loop1 on top of /dev/sdb1 with 256-bit blowfish encryption.

What happened:
--------------

Everything would work fine for a while, but when copying large amounts of data
into AFS, kupdated and a fileserver process or two would hang. This was mainly
apparent when copying data from a local filesystem on the server into /afs/...

This would hang every client on the network accessing resources in AFS. Since 
the hung (server) processes were unkillable, we had to bounce the fileserver with 
the partitions still mounted, "reboot -f -n". We couldn't even run sync. Ouch.

We tried disabling afsd's disk cache on the server, compiling a non-SMP kernel, 
and installing the latest openafs snapshot, all to no avail. Then we found this 
post on the Linux kernel mailing list: 

http://lists.insecure.org/linux-kernel/2002/Mar/0696.html

Which suggested a tweak to /proc/sys/vm/bdflush.

Fix:
----

echo 10 0 0 0 500 3000 25 0 0 > /proc/sys/vm/bdflush 

Seems to have fixed our lockup problems. (At least, operations which used to 
consistently hang the machine now work fine).

I'm not sure if this is a problem with vanilla loopback or whether it only occurs
when using encrypted loopback devices, but I hope this saves at least one other 
person some sleep-dep :)

Best regards,

    Blair Strang

-- 
The probability of someone watching you is proportional to the
stupidity of your action.