Re: [PATCH 2.6.20] updated dm-loop patch

["Bryn M. Reeves" <breeves@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2588 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

roland wrote:
> Hi Bryn,
> 
> after some first tests which looked very very promising (could dmlosetup
> files >2gb, could create more than 256 loop dm-loop devices...), i have
> bad news.
> maybe it`s not that "bad" because you may be able to fix it quickly, but
> it seems that dm-loop is racy (or whatever). maybe smp safeness, since i
> was testing on a P4 with HT enabled ? i did my first tests on non-smp
> system (VM), but it wasn`t put under that load as i did now.

Hi Roland,

At first sight, this doesn't look SMP related. The backtrace you posted
comes from a BUG() macro in the source that triggers when we can't find
an extent we're looking for in the table.

There's also a rather odd number in the "not using" message:

device-mapper: loop: not using 4294967296 bytes in incomplete block at EOF

So I think for some reason we're not building a correct block map for
this file.

I'll have time to take a proper look at this this evening - while I'm
looking into this one, do you have any other info on the file that gave
the problem:

- - was it a sparse file?
- - was an offset used when creating the device?

If you have the time, I'd also be interested in seeing the following
information:

- - output of dmsetup table <device>
- - debugfs output for the loop file concerned

For the first one, there's no need to perform any I/O to the device
after creating it, so you shouldn't need to trigger the BUG() again - it
might help to kill udevd though, as it will try to run vol_id etc. on
the device otherwise.

For the debugfs data, please run the attached script on the device/file
that had the problem, for e.g.:

do_debugfs.sh /dev/hda3 src/5gig.dat > /tmp/5gig.dat.out

The first argument is the device containing the file and the second is
the path relative to the device's root directory - change the
path/device to suit your system.

This will give a complete block map for the file so I can see what we're
tripping over. For a 5G file this may take a few minutes and the file
will be 50-100k in size - you can send it to me privately rather than
spamming the whole list :)

> ps:
> hey, why not announcing this on lkml, so this gut get some more notice
> or being reviewed by others?

So that we can work these kind of problems out first! ;)

Kind regards,

Bryn.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFF0Iai6YSQoMYUY94RAiNmAKC99G8+slz+tVDnSkCiVsPN6GVoJwCeJcCg
wQ3iLG/ZVzGsualWfcmVv34=
=y8/d
-----END PGP SIGNATURE-----

[-- Attachment #2: do_debugfs.sh --]
[-- Type: application/x-shellscript, Size: 286 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]