>> I have to admit that I wasn't aware of any such bug, and I
>> regularly use that very option to mount cd images for testing
>> prior to burning them out, and have never had any indication of
>> a bug being present. As a result, I would be VERY interested in
>> details of this bug as it exists in current 2.2 kernels.
> ~~~~~~~
> It seems to be not present in 2.2.12.
That's good to hear.
> The bug was present in 2.2.7 and I mailed to tytso@mit.edu on 10
> May and it (bug) seems to have disappeared but now we have
> something even more interesting.
> Attempt to use the "-o loop=/dev/loop0" syntax as in...
> dd if=/dev/zero of=image bs=4096 count=1000
> mke2fs image
> mount -t ext2 -o loop=/dev/loop0 image /mnt
> ...results in a massive (infinite?) amount of messages in kernel
> log saying "hm, busy page invalidated? (not necesserily a
> bug)\n" coming from invalidate_inode_pages() of mm/filemap.c
> (this is 2.3.19).
I don't run the 2.3 kernels myself, but I'll have a look in the syslog
on my 2.2.12 system later this evening when I get home, and see if the
same is happenning there.
One obvious question though: Was /dev/loop0 already in use when you
did that? I've always used simply "-o loop" which uses the first
unused loop device, so have no idea what happens if one tries to reuse
one that's already in use.
One thing to remember is that if one used `mount -o loop` then the
relevant `umount` command will automatically clear the loop devicxe as
well, but if one does the losetup separately, then the `umount` does
not clear the loop device afterwards.
> Note that I do NOT get all these messages if do losetup
> /dev/loop0 image first and then mount -t ext /dev/loop0 /mnt.
That would tend to indicate that the problem is not a kernel bug, but
some sort of synchronisation problem with the loop devices.
> A different topic, of course - but something worth looking at,
> nevertheless.
Very true. Can you try the following and see if that also produces
wads of syslog messages please?
Q> dd if=/dev/zero bs=1024 count=4000 of=/tmp/looptest
Q> mke2fs /tmp/looptest
Q> mount -o loop /tmp/looptest /mnt
The results will probably help to locate the problem, when compared
with your earlier results.
> Anyway, you convinced me - I went back to redhat default static
> /etc/mtab. I only disliked it because it seemed like a waste of
> a few CPU cycles creating it on each boot. But if there are
> reasons to have it - so be it.
Unless I'm mistaken, the default RedHat startup script will use MORE
CPU cycles with the symlink in place than without, since it still
tries to write to the file, and has to handle the "Read-only file"
errors resulting from doing so, which it wouldn't have had to handle
otherwise...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/