[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [PATCH 2.6.20] updated dm-loop patch

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

- - 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,


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


Attachment: do_debugfs.sh
Description: application/shellscript

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]