It appears that the loopback-hang parasite is alive and well in 2.4.1-ac5.
I've done several tests and I thus provide the following information:
The bug is independent of UP or SMP configured.. it hung both ways, but the
box itself is UP.
It appears to hang when internal buffers get filled. The way I see it, copying
files from disk to the loopback device (which is a file on the same disk)
begins to read from the disk. When the internal read buffer is full, the
kernel's queued writes start activating and the data gets copied to the
loopback file. This process repeats over and over, as it should normally.
Sometimes however, during a read from the disk, it fills up its buffers and
then never makes the accompanying write. In fact, the entire device freezes on
the read.
I was able to lessen the frequency of hanging by using the -v flag and tapping
^S and ^Q to temporarily 'pause' copying. This ensures that the read buffer
will never become full to the point where it could cause the hang, and appears
to work -- until it came across the libc.a file. There was no way to pause it
here because nothing is being outputted to the screen while it's copying
libc.a. Unfortunately, it fills the buffer too quick and hangs 100% every time.
The disk is totally nonresponsive at this point, and a hard reset is necessary.
I hope this helps anyone who is still tracking down the loopback problem.
Regards,
Byron
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [email protected]
> It appears that the loopback-hang parasite is alive and well in 2.4.1-ac5.
> I've done several tests and I thus provide the following information:
>
> The bug is independent of UP or SMP configured.. it hung both ways, but the
> box itself is UP.
>
> It appears to hang when internal buffers get filled. The way I see it, copying
> files from disk to the loopback device (which is a file on the same disk)
> begins to read from the disk. When the internal read buffer is full, the
> kernel's queued writes start activating and the data gets copied to the
> loopback file. This process repeats over and over, as it should normally.
>
> Sometimes however, during a read from the disk, it fills up its buffers and
> then never makes the accompanying write. In fact, the entire device freezes on
> the read.
>
> I was able to lessen the frequency of hanging by using the -v flag and tapping
> ^S and ^Q to temporarily 'pause' copying. This ensures that the read buffer
> will never become full to the point where it could cause the hang, and appears
> to work -- until it came across the libc.a file. There was no way to pause it
> here because nothing is being outputted to the screen while it's copying
> libc.a. Unfortunately, it fills the buffer too quick and hangs 100% every time.
> The disk is totally nonresponsive at this point, and a hard reset is necessary.
>
> I hope this helps anyone who is still tracking down the loopback problem.
>
> Regards,
> Byron
>
> --
> Byron Stanoszek Ph: (330) 644-3059
I can confirm this. The system totally locks when this occurs. I let
it sit all night when it did this the last time, and it didn't
recover.
It requires a large file transfer to usually invoke it.
Billy
FYI following hints from the linux-crypto mailing-list archives, I am
using the following configuration :
linux-2.4.0
patch-int-2.4.0.3
http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-1.gz
http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-bdev-inc-1.gz
util-linux-2.10o
Documentation/crypto/util-linux-2.10o.patch
I setup an encrypted 2097152000 byte loopback partition and moved
800MB of data there, including a 90MB file.
My only problems are:
- rc.d/init.d/S01reboot sometimes fails to unmount partitions with
loop files on them (this already happened with 2.2.17).
- losetup after losetup -d sometimes fails.
-- Pascal
The same here. I have had no problems with either 2.4.0 or 2.4.1,
and I don't even have the Axboe's patch applied. Which makes me
wonder where is the problem.
I am also using encryption (patch-int-2.4.0.3, idea cipher) and
util-linux-2.10o. The container file is not as big, only 256MB
with 65MB of data, and the largest file is ~30MB. I had to
convert from the blowfish and used dump|restore. There were no
problems whatsoever.
Dejan
On Thu, Feb 08, 2001 at 03:48:34AM +0100, Pascal Brisset wrote:
> FYI following hints from the linux-crypto mailing-list archives, I am
> using the following configuration :
>
> linux-2.4.0
> patch-int-2.4.0.3
> http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-1.gz
> http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-bdev-inc-1.gz
> util-linux-2.10o
> Documentation/crypto/util-linux-2.10o.patch
>
> I setup an encrypted 2097152000 byte loopback partition and moved
> 800MB of data there, including a 90MB file.
>
> My only problems are:
> - rc.d/init.d/S01reboot sometimes fails to unmount partitions with
> loop files on them (this already happened with 2.2.17).
> - losetup after losetup -d sometimes fails.
>
> -- Pascal
>
>
> Linux-crypto: cryptography in and on the Linux system
> Archive: http://mail.nl.linux.org/linux-crypto/