loop problem with Linux Mint 4.0 KDE

[SoFresh]

I found something strange, and anoying for me: I'm unable to use /dev/loop[0-9]

How to reproduce:
Have some free space on a disk
Boot Mint Live 4.0 KDE (probably also works with other versions)
Open a terminal and type:
# sudo mkdir /mnt/1
# sudo mkdir /mnt/2
# sudo mount /dev/sd[your_partition_here] /mnt/1

Let's create a virtual partition
# sudo dd if=/dev/zero of=/mnt/1/virtual bs=1M count=2000

Use this virtual partition inside a loop device:
# sudo losetup -f
--> /dev/loop1
# sudo losetup /dev/loop1 /mnt/1/virtual

First test:
# sudo dd if=/dev/zero of=/dev/loop1 bs=1M
--> some datas are written and sometimes the process stop responding
--> and sometimes everything is fine. Depend of what ?

Create a filesystem:
# sudo mkfs.ext2 /dev/loop1

And mount it:
# sudo mount /dev/loop1 /mnt/2

Check it:
# df -h
--> 2 Gb free on /mnt/2

Test 2:
# sudo dd if=/dev/zero of=/mnt/2/bigone bs=1M
--> this test generally never end
--> datas start to be written, then nothing happens
--> iostat show either 50% iowait, or 50% system on a dual core CPU

I tested this on two different computers with Linux Mint Live 4.0 KDE.
AMD 4200+ 1 Gb
Intel Celron 1 Gb

I also tested with Debian Etch, and you can see the bug report here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483830

Fedora 9 Live don't have this behaviour.
The lastest Ubuntu don't have this behaviour.

[SoFresh]

Anyone can test this to confirm the problem, or to see if it's me ?

[Husse]

Only from the live DVD?
Have you tested the installed version?
When it comes to things like this it may vary between installed and live DVD
(Note -I'm no expert in the field - but I can handle it if I go slowly )

[SoFresh]

Only from the live DVD?
Have you tested the installed version?

I tested both on two different computers. Same problem.

[Husse]

What about mounting an ISO - does the loop there work?

[SoFresh]

What about mounting an ISO - does the loop there work?

In lieu of asking questions, maybe you can do the test yourself ? This is only a boot away from you.
Seems this is a real bug... and seems nobody take care of it

[AK Dave]

Seems to be a Debian problem. If so, you can probably also reproduce the same problem on Ubuntu and other Debian derivatives.

You provide steps to replicate the problem, but don't appear to be interested in helping to solve the problem. I don't have a practical reason to mount loopback the exact way that you're doing it, and the practical ways that I do use loopback don't have any problems, so I'm not experiencing this particular error in real-world application. What are you trying to do where this apparant error is a problem?

My thought is that Ubuntu is also Debian-derivative, the problem should replicate on Ubuntu, and Ubuntu has more developer resources to tackle what appears to be an obscure and insidious bug. Does it make sense that the bug is real and affects Mint, but ubuntuforums might be the better place to report and track it than linuxmint/forum?

[SoFresh]

Seems to be a Debian problem.

This is why I mentionned this link at the end of my post:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483830

I post here because Debian devloppers seems to have better things to do

If so, you can probably also reproduce the same problem on Ubuntu and other Debian derivatives.

The last line of my post is clear about that.

What are you trying to do where this apparant error is a problem?

I just want to use loop devices to write to iso images, to write to vmware images, and to write to some crypto images. None work with stock kernels.
My own computer can't use loop at all (except we I only read from, or when I write very few things) because I use Linux Mint.

(you)don't appear to be interested in helping to solve the problem.

Why do you think I post here ?
Why do you think I ask other people to "please test this" ?
Why I tested this on several computers, with several distributions ?
Why I compiled different kernels to see if things change ?

I'm here just to have other people to confirm (or not) the problem. Because until now, in my own point of view, nobody can safely write via loop devices. As this seems impossible, maybe with some other people we can understand why on some computers this is okay, and on some other not.

[AK Dave]

You say you can't reproduce this on the "latest Ubuntu". Daryna isn't based on the "latest Ubuntu". Problems fixed in Ubuntu-Hardy might remain unfixed in Mint-Daryna, but would be expected to be fixed in Mint-Elyssa. Some problems are fixed in Ubuntu with the server kernel instead of the generic kernel, due to different compile settings. Different kernel compile settings may also explain why the problem doesn't exist in Fedora, although you're sparse on details and it appears you're trying to do this from a LiveCD instead of an actual install. Some problems exist in a LiveCD but not in an actual install, and vice-versa. I, for example, find Mandriva to have desktop eyecandy features that only work from the LiveCD but are broken on actual install.

When you say "Mint 4.0 KDE", I assume "with all available upgrades already patched. When you say "Fedora 9", I assume "full install, full upgrades, not running under vmware". When you say "AMD 4200+ 1 Gb", I assume "real computer, not a vmware session." But you talk of vmware and your initial report is weak on specifics, so I don't know if I'm safe in my assumptions.

Things to consider:
1. Are you running these test OS versions from full install, LiveCD, vmware virtualization of install, or vmware virtualization of LiveCD?
2. Can you reproduce the bug in Elyssa? If this is fixed in Hardy, it should be fixed in Elyssa.
3. Can you reproduce the bug in Ubuntu Gutsy? If this is broke in Daryna, it should be broke in Gutsy.
4. This is broke in Lenny, Etch, etc. Is it still broke if you upgrade or recompile the kernel?
5. Can you fix the problem in any of the distros where it is manifest with a non-stock kernel? If so, how?

The Debian developers may "have better things to do" because the problem is fixed in Ubuntu Hardy and the fix just needs to propogate back to Debian. If the problem is fixed (or not reproducable, which isn't necessarily the "same thing") in Hardy, fixed in Elyssa, then run Elyssa or Hardy.

From what I can gather, my guess is that your problem is related to the iowait error - a known Gutsy bug fixed in Hardy. If true, then I'm not at all surprised the problem exists in Daryna (same guts as Gutsy), and would be surprised if the problem exists in Elyssa. Furthermore, a kernel upgrade to Lenny should fix it also - assuming that Hardy's fix is already backported to Lenny. But the same kernel fix might not be available in Daryna, or might require a custom recompile. Has this been attempted?

There is a problem. It manifests in some distro installs and not in others. The distros where the problem doesn't manifest have newer kernels.