device-mapper oops (and more!)

Molle Bestefich molle.bestefich at gmail.com
Sat Feb 12 11:23:02 UTC 2005


Hi

A status update on my experience with dmraid and the device-mapper.

Topics, ranging from "least serious" (1) to most (4):

  1. 'dmraid' and device-mapper target availability
  2. Error message propagation from device-mapper through dmraid to end user
  3. Assembly of mirrors using dmraid
  4. Oops while using dmraid / device-mapper


--__--__--

Topic 1: 'dmraid' and device-mapper target availability

Dmraid does not check for available targets before trying to assemble arrays.

Example:
If I run 'dmraid -ay', dmraid tries to create device-mapper tables
using the 'mirror' target,
even though dmsetup does not list "mirror" support in 'dmsetup targets'.
(The mirror target is not compiled in and there is no dm-mirror.ko available.)


--__--__--

Topic 2: Error message propagation from device-mapper through dmraid to end user

When the device-mapper fails to do something for dmraid, the error
does not get propagated to the end user.
Sometimes there is a follow-on error from dmraid, sometimes there is
no indication at all that something is wrong.
The device-mapper errors, however, is in the syslog, so it should be
possible to show them to the end user?

Examples of device mapper error messages in attached syslog_{1,2}.txt.
Example of follow-on error message from dmraid:

ERROR: dos: reading /dev/mapper/hpt45x_bbdfhdjicg[2]


--__--__--

Topic 3: Assembly of mirrors using dmraid

'dmraid' does not assembly the mirror on a HPT controller correctly.
An error message is provided in the syslog from device-mapper, saying:

device-mapper: device /dev/mapper/hpt45x_bbdfhdjicg too small for target

It seems that dmraid / the device-mapper (dunno which is responsible)
builds a 40 GB mirror, when in fact it should have been 80 GB.  Dmraid
then proceeds to try and add tables (or what's it called?) for the
first partition, which happens to be 60 GB in size, and device-mapper
reports that it has failed to do this, with good reason I might add.

The resulting /dev/mapper/hpt45x_bbdfhdjicg1 device is 0 bytes in
size, so 'mount' etc. of course fails.

How I found out (forgive me, but I think that it's rather clever :-)):

I have two test setups, one where Linux runs directly on the hardware
and one where it runs in a VMware which emulates physical access to
the disks in the system.  Using the direct approach, dmraid and
device-mapper does disk layout.  Using the emulated approach, access
goes through a BusLogic SCSI driver and the Windows drivers for the
HPT controller, so Linux sees the correct disk layout as physical
disks.

'fdisk -l' output from both test environments is attached; check out
the 40 GB vs. 80 GB difference:

device-mapper / dmraid:  Disk /dev/mapper/hpt45x_bbdfhdjicg: 40.0 GB,
40013178368 bytes
Windows HPT374 driver:   Disk /dev/sda: 80.0 GB, 80023749120 bytes


--__--__--

Topic 4: Oops while using dmraid / device-mapper

I got this oops in kmirrord after activating and deactivating randomly
a couple (3-4) times:

livecd root # dmraid -ay
Oops: 0000 [#1]
EIP:    0060:[<c02a1032>]    Not tainted VLI
EFLAGS: 00010246   (2.6.9)
EIP is at find_next_zero_bit+0x82/0xa4
eax: ffffffff   ebx: f8d35000   ecx: 07fffd10   edx: 00000000
esi: 00000000   edi: f8d35000   ebp: ffffa1f2   esp: f7ccbeb0
ds: 007b   es: 007b   ss: 0068
Process kmirrord/0 (pid: 6721, threadinfo=f7cca000 task=dfc01000)
Stack: 00000000 f8d0f000 0012a1f2 f7dc3480 f7ccbef0 f8ca9a21 f8d0f000 0012a1f2
       00130000 c19dfdb0 c19dfd8c c19dfd80 c19dfd8c f8caa507 f74644e0 f7ccbef0
       0012ffff 00000000 c19dfdb0 c19dfd8c c19dfd80 f74644e0 f8caa5c6 c19dfd8c
Call Trace:
 [<f8ca9a21>] core_get_resync_work+0x31/0x80 [dm_mirror]
 [...]

Above is only a snippet; rest of the oops message is attached separately.


--__--__--

I cross-posted this to two mailing lists, since topics 4 and perhaps 2
is probably relevant for device-mapper folks.  Hope it's ok?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: syslog_1.txt
URL: <http://listman.redhat.com/archives/ataraid-list/attachments/20050212/d3598ad6/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: syslog_2.txt
URL: <http://listman.redhat.com/archives/ataraid-list/attachments/20050212/d3598ad6/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fdisk_l__linux_dm.txt
URL: <http://listman.redhat.com/archives/ataraid-list/attachments/20050212/d3598ad6/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fdisk_l__windows_driver.txt
URL: <http://listman.redhat.com/archives/ataraid-list/attachments/20050212/d3598ad6/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: oops.txt
URL: <http://listman.redhat.com/archives/ataraid-list/attachments/20050212/d3598ad6/attachment-0004.txt>


More information about the Ataraid-list mailing list