Quote Originally Posted by garyng
I have seen something related but in different situation. I am working on a broken man's install by loop mount the complete ISO, then cloop mount the compressed file system and saw this iffy behaviour too. Sometimes, it just hang there when it tries to start X, sometimes it works. That is when I put the ISO on a FAT partition.

When I put the ISO file on a NTFS partition, I am surprised to see that I can do this even using the 1.x NTFS drive but for this situation, it hangs ever time if I start X but seems to be working normally if I just stay at the command line(so I believe it is also load related).

Surprisingly, if I extract the clooped file and put it on NTFS partiton, I cannot cloop mount it directly(Segment fault), but if I go through the 9660 system->cloop, I can mount it but not very reliable.

Seems that there is changes in the kernel that cause all these.
The problem seem to have existed in cloop even with older kernels but was rarely showing up under normal conditions. It seems that normal operation or even heavy (but single-threaded) reading doesn't trigger it. What triggers it fastest is a lot of simultaneous reading tasks. Try running a few find(1) processes which exec something like wc or sum on many files in cloop and you're likely to trigger it. Starting OpenOffice while doing some other disk ops is also a good way

The problem became much worse with recent (unofficial) kernels. With 2.4.22-pre7 and beyond (last I tested was 2.4.22-rc2), I get stuck while still in linuxrc, unless I place some sleeps and syncs there. Kernel 2.4.22-pre2 works pretty well with it, so some change between pre2 and pre7 makes the problem appear much faster than before. I'll check the diffs...

Since it happens only when several tasks are reading simultaneously, I expect it to be a deadlock, probably outside cloop code. It seem to happen faster when I use more block-dev related drivers at the same time (such as usb-storage + sd).

I'll dig into it soon and see what I can find. I wish Linux had a good mutex-analysis kernel-level tool. (Or maybe there is already one and I'm not aware of it).

At the moment, its only a problem for us users who like to use bleeding-edge kernels, but I'm afraid once the official 2.4.22 is out, it'll become everybody's problem.