multipath-tools causes path to come back as different block device

multipath-tools causes path to come back as different block device

[Brian De Wolf]

Hello again,

I've been testing multipath-tool's rdac capability with a qla2xxx HBA and an IBM
DS4800 some more and I've hit another stumbling block.  When I test unplugging
one of the HBA ports and plugging it back in with multipath running, it seems to
cause bad things to happen.  Here is what the syslog looks like (note:  sdb is a
path, sdd is initially unused, and sde is the second path):

Jul 19 14:30:35 jimbo kernel: qla2xxx 0000:02:01.1: LOOP DOWN detected (2).
Jul 19 14:30:41 jimbo kernel: rport-4:0-0: blocked FC remote port time out:
removing target and saving binding
Jul 19 14:30:41 jimbo kernel: sd 4:0:0:0: [sde] Synchronizing SCSI cache
Jul 19 14:30:41 jimbo kernel: sd 4:0:0:0: [sde] Result: hostbyte=0x01
driverbyte=0x00
Jul 19 14:30:48 jimbo multipathd: sde: rdac checker reports path is down
Jul 19 14:30:48 jimbo multipathd: checker failed path 8:64 in map test
Jul 19 14:30:48 jimbo kernel: scsi 4:0:0:0: rejecting I/O to dead device
Jul 19 14:30:48 jimbo kernel: device-mapper: multipath: Failing path 8:64.
Jul 19 14:30:48 jimbo multipathd: test: remaining active paths: 1
Jul 19 14:30:48 jimbo multipathd: test: switch to path group #2
Jul 19 14:30:52 jimbo kernel: qla2xxx 0000:02:01.1: LIP reset occured (f700).
Jul 19 14:30:52 jimbo kernel: qla2xxx 0000:02:01.1: LIP occured (f700).
Jul 19 14:30:52 jimbo kernel: qla2xxx 0000:02:01.1: LIP reset occured (f7f7).
Jul 19 14:30:53 jimbo kernel: scsi 4:0:0:0: rejecting I/O to dead device
Jul 19 14:30:53 jimbo multipathd: sde: rdac checker reports path is down
Jul 19 14:30:53 jimbo kernel: qla2xxx 0000:02:01.1: LOOP UP detected (4 Gbps).
Jul 19 14:30:53 jimbo kernel: scsi 4:0:0:0: Direct-Access     IBM      1815
 FAStT  0914 PQ: 0 ANSI: 3
Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] 6291456 512-byte hardware
sectors (3221 MB)
Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Write Protect is off
Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Mode Sense: 77 00 10 08
Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Write cache: enabled, read
cache: enabled, supports DPO and FUA
Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] 6291456 512-byte hardware
sectors (3221 MB)
Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Write Protect is off
Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Mode Sense: 77 00 10 08
Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Write cache: enabled, read
cache: enabled, supports DPO and FUA
Jul 19 14:30:53 jimbo kernel: sdd: sdd1
Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Attached SCSI disk
Jul 19 14:30:53 jimbo kernel: scsi 4:0:0:0: Direct-Access     IBM      1815
 FAStT  0914 PQ: 0 ANSI: 3
Jul 19 14:30:53 jimbo kernel: kobject_add failed for 4:0:0:0 with -EEXIST, don't
try to register things with the same name in the same directory.
Jul 19 14:30:53 jimbo kernel:
Jul 19 14:30:53 jimbo kernel: Call Trace:
Jul 19 14:30:53 jimbo kernel: [<ffffffff802e1d9b>] kobject_shadow_add+0x187/0x191
Jul 19 14:30:53 jimbo kernel: [<ffffffff8033a495>] device_add+0xa1/0x59d
Jul 19 14:30:53 jimbo kernel: [<ffffffff803638e8>] scsi_sysfs_add_sdev+0x2e/0x24a
Jul 19 14:30:53 jimbo kernel: [<ffffffff80361f18>]
scsi_probe_and_add_lun+0x6ff/0x80f
Jul 19 14:30:53 jimbo kernel: [<ffffffff803612c8>] scsi_alloc_sdev+0x195/0x1ea
Jul 19 14:30:53 jimbo kernel: [<ffffffff80362580>] __scsi_scan_target+0x3e9/0x549
Jul 19 14:30:53 jimbo kernel: [<ffffffff80416d83>] thread_return+0x0/0xe2
Jul 19 14:30:53 jimbo kernel: [<ffffffff80362777>] scsi_scan_target+0x97/0xbc
Jul 19 14:30:53 jimbo kernel: [<ffffffff88003668>]
:scsi_transport_fc:fc_scsi_scan_rport+0x59/0x79
Jul 19 14:30:53 jimbo kernel: [<ffffffff8800360f>]
:scsi_transport_fc:fc_scsi_scan_rport+0x0/0x79
Jul 19 14:30:53 jimbo kernel: [<ffffffff802379c4>] run_workqueue+0x84/0x105
Jul 19 14:30:53 jimbo kernel: [<ffffffff80237a45>] worker_thread+0x0/0xf4
Jul 19 14:30:53 jimbo kernel: [<ffffffff80237b2f>] worker_thread+0xea/0xf4
Jul 19 14:30:53 jimbo kernel: [<ffffffff8023addd>] autoremove_wake_function+0x0/0x2e
Jul 19 14:30:53 jimbo kernel: [<ffffffff8023addd>] autoremove_wake_function+0x0/0x2e
Jul 19 14:30:53 jimbo kernel: [<ffffffff8023a888>] kthread+0x3d/0x63
Jul 19 14:30:53 jimbo kernel: [<ffffffff8020a338>] child_rip+0xa/0x12
Jul 19 14:30:53 jimbo kernel: [<ffffffff8023a84b>] kthread+0x0/0x63
Jul 19 14:30:53 jimbo kernel: [<ffffffff8020a32e>] child_rip+0x0/0x12
Jul 19 14:30:53 jimbo kernel:
Jul 19 14:30:53 jimbo kernel: error 1
Jul 19 14:30:53 jimbo kernel: scsi 4:0:0:0: Unexpected response from lun 0 while
scanning, scan aborted
Jul 19 14:30:53 jimbo scsi.agent[8613]: disk at
/devices/pci0000:00/0000:00:02.0/0000:02:01.1/host4/rport-4:0-0/target4:0:0/4:0:0:0
Jul 19 14:30:53 jimbo multipathd: sdd: add path (uevent)
Jul 19 14:30:53 jimbo kernel: scsi 4:0:0:0: rejecting I/O to dead device
Jul 19 14:30:53 jimbo multipathd: sde: checker msg is "rdac checker reports path
is down"
Jul 19 14:30:53 jimbo kernel: device-mapper: multipath rdac: using RDAC command
with timeout 15000
Jul 19 14:30:53 jimbo kernel: device-mapper: table: 254:6: multipath: error
getting device
Jul 19 14:30:53 jimbo kernel: device-mapper: ioctl: error adding target to table
Jul 19 14:30:53 jimbo multipathd: test: failed in domap for addition of new path sdd
Jul 19 14:30:53 jimbo multipathd: test: uev_add_path sleep
...

From here, the last 5 lines get repeated until I 'kill -9' the multipathd
process.  I'm not too keen on kernel internals (though playing with multipathing
is bringing me up to speed pretty quick), but I'm wondering if multipathd is
causing the call trace by not letting /dev/sde disappear so that the HBA's scsi
device can grab that name again.  I noticed this via lsof:
multipath 8390     root    5r      BLK               8,64              22254
/dev/sde (deleted)
multipath 8390     root    6r      BLK               8,16               1100
/dev/sdb
multipath 8390     root   10r      BLK               8,48              23647
/dev/sdd

When multipathd is running, unplugging and plugging in one of the ports causes
it to grab the next sd* device name.  As this is repeated, the number of deleted
block devices multipathd holds on to grows, along with the number of unhappy
rdac checkers.  As I said before, it takes a 'kill -9' to stop multipathd, and
subsequent plugging ins choose sd* names that were previously used but were held
onto as (deleted) by multipathd.

However, this behavior is not seen when multipathd is not running.  When the
port is unplugged, the /dev/sd* device disappears, and when it is plugged back
in, it takes the same name it had before (I assume it's just taking the lowest
name, and its old name has been freed) cleanly, with no call traces or anything.

Any ideas on how to correct this behavior?

Thanks!
Brian De Wolf

Re: multipath-tools causes path to come back as different block device

[Hannes Reinecke]

Brian De Wolf wrote:
> Hello again,
> 
> I've been testing multipath-tool's rdac capability with a qla2xxx HBA and an IBM
> DS4800 some more and I've hit another stumbling block.  When I test unplugging
> one of the HBA ports and plugging it back in with multipath running, it seems to
> cause bad things to happen.  Here is what the syslog looks like (note:  sdb is a
> path, sdd is initially unused, and sde is the second path):
> 
> Jul 19 14:30:35 jimbo kernel: qla2xxx 0000:02:01.1: LOOP DOWN detected (2).
> Jul 19 14:30:41 jimbo kernel: rport-4:0-0: blocked FC remote port time out:
> removing target and saving binding
> Jul 19 14:30:41 jimbo kernel: sd 4:0:0:0: [sde] Synchronizing SCSI cache
> Jul 19 14:30:41 jimbo kernel: sd 4:0:0:0: [sde] Result: hostbyte=0x01
> driverbyte=0x00
> Jul 19 14:30:48 jimbo multipathd: sde: rdac checker reports path is down
> Jul 19 14:30:48 jimbo multipathd: checker failed path 8:64 in map test
> Jul 19 14:30:48 jimbo kernel: scsi 4:0:0:0: rejecting I/O to dead device
> Jul 19 14:30:48 jimbo kernel: device-mapper: multipath: Failing path 8:64.
> Jul 19 14:30:48 jimbo multipathd: test: remaining active paths: 1
> Jul 19 14:30:48 jimbo multipathd: test: switch to path group #2
> Jul 19 14:30:52 jimbo kernel: qla2xxx 0000:02:01.1: LIP reset occured (f700).
> Jul 19 14:30:52 jimbo kernel: qla2xxx 0000:02:01.1: LIP occured (f700).
> Jul 19 14:30:52 jimbo kernel: qla2xxx 0000:02:01.1: LIP reset occured (f7f7).
> Jul 19 14:30:53 jimbo kernel: scsi 4:0:0:0: rejecting I/O to dead device
> Jul 19 14:30:53 jimbo multipathd: sde: rdac checker reports path is down
> Jul 19 14:30:53 jimbo kernel: qla2xxx 0000:02:01.1: LOOP UP detected (4 Gbps).
> Jul 19 14:30:53 jimbo kernel: scsi 4:0:0:0: Direct-Access     IBM      1815
>  FAStT  0914 PQ: 0 ANSI: 3
> Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] 6291456 512-byte hardware
> sectors (3221 MB)
> Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Write Protect is off
> Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Mode Sense: 77 00 10 08
> Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Write cache: enabled, read
> cache: enabled, supports DPO and FUA
> Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] 6291456 512-byte hardware
> sectors (3221 MB)
> Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Write Protect is off
> Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Mode Sense: 77 00 10 08
> Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Write cache: enabled, read
> cache: enabled, supports DPO and FUA
> Jul 19 14:30:53 jimbo kernel: sdd: sdd1
> Jul 19 14:30:53 jimbo kernel: sd 4:0:0:0: [sdd] Attached SCSI disk
> Jul 19 14:30:53 jimbo kernel: scsi 4:0:0:0: Direct-Access     IBM      1815
>  FAStT  0914 PQ: 0 ANSI: 3
> Jul 19 14:30:53 jimbo kernel: kobject_add failed for 4:0:0:0 with -EEXIST, don't
> try to register things with the same name in the same directory.
> Jul 19 14:30:53 jimbo kernel:
> Jul 19 14:30:53 jimbo kernel: Call Trace:
> Jul 19 14:30:53 jimbo kernel: [<ffffffff802e1d9b>] kobject_shadow_add+0x187/0x191
> Jul 19 14:30:53 jimbo kernel: [<ffffffff8033a495>] device_add+0xa1/0x59d
> Jul 19 14:30:53 jimbo kernel: [<ffffffff803638e8>] scsi_sysfs_add_sdev+0x2e/0x24a
> Jul 19 14:30:53 jimbo kernel: [<ffffffff80361f18>]
> scsi_probe_and_add_lun+0x6ff/0x80f
> Jul 19 14:30:53 jimbo kernel: [<ffffffff803612c8>] scsi_alloc_sdev+0x195/0x1ea
> Jul 19 14:30:53 jimbo kernel: [<ffffffff80362580>] __scsi_scan_target+0x3e9/0x549
> Jul 19 14:30:53 jimbo kernel: [<ffffffff80416d83>] thread_return+0x0/0xe2
> Jul 19 14:30:53 jimbo kernel: [<ffffffff80362777>] scsi_scan_target+0x97/0xbc
> Jul 19 14:30:53 jimbo kernel: [<ffffffff88003668>]
> :scsi_transport_fc:fc_scsi_scan_rport+0x59/0x79
> Jul 19 14:30:53 jimbo kernel: [<ffffffff8800360f>]
> :scsi_transport_fc:fc_scsi_scan_rport+0x0/0x79
> Jul 19 14:30:53 jimbo kernel: [<ffffffff802379c4>] run_workqueue+0x84/0x105
> Jul 19 14:30:53 jimbo kernel: [<ffffffff80237a45>] worker_thread+0x0/0xf4
> Jul 19 14:30:53 jimbo kernel: [<ffffffff80237b2f>] worker_thread+0xea/0xf4
> Jul 19 14:30:53 jimbo kernel: [<ffffffff8023addd>] autoremove_wake_function+0x0/0x2e
> Jul 19 14:30:53 jimbo kernel: [<ffffffff8023addd>] autoremove_wake_function+0x0/0x2e
> Jul 19 14:30:53 jimbo kernel: [<ffffffff8023a888>] kthread+0x3d/0x63
> Jul 19 14:30:53 jimbo kernel: [<ffffffff8020a338>] child_rip+0xa/0x12
> Jul 19 14:30:53 jimbo kernel: [<ffffffff8023a84b>] kthread+0x0/0x63
> Jul 19 14:30:53 jimbo kernel: [<ffffffff8020a32e>] child_rip+0x0/0x12
> Jul 19 14:30:53 jimbo kernel:
> Jul 19 14:30:53 jimbo kernel: error 1
> Jul 19 14:30:53 jimbo kernel: scsi 4:0:0:0: Unexpected response from lun 0 while
> scanning, scan aborted
> Jul 19 14:30:53 jimbo scsi.agent[8613]: disk at
> /devices/pci0000:00/0000:00:02.0/0000:02:01.1/host4/rport-4:0-0/target4:0:0/4:0:0:0
> Jul 19 14:30:53 jimbo multipathd: sdd: add path (uevent)
> Jul 19 14:30:53 jimbo kernel: scsi 4:0:0:0: rejecting I/O to dead device
> Jul 19 14:30:53 jimbo multipathd: sde: checker msg is "rdac checker reports path
> is down"
> Jul 19 14:30:53 jimbo kernel: device-mapper: multipath rdac: using RDAC command
> with timeout 15000
> Jul 19 14:30:53 jimbo kernel: device-mapper: table: 254:6: multipath: error
> getting device
> Jul 19 14:30:53 jimbo kernel: device-mapper: ioctl: error adding target to table
> Jul 19 14:30:53 jimbo multipathd: test: failed in domap for addition of new path sdd
> Jul 19 14:30:53 jimbo multipathd: test: uev_add_path sleep
> ...
> 
>>From here, the last 5 lines get repeated until I 'kill -9' the multipathd
> process.  I'm not too keen on kernel internals (though playing with multipathing
> is bringing me up to speed pretty quick), but I'm wondering if multipathd is
> causing the call trace by not letting /dev/sde disappear so that the HBA's scsi
> device can grab that name again.  I noticed this via lsof:
> multipath 8390     root    5r      BLK               8,64              22254
> /dev/sde (deleted)
> multipath 8390     root    6r      BLK               8,16               1100
> /dev/sdb
> multipath 8390     root   10r      BLK               8,48              23647
> /dev/sdd
> 
> When multipathd is running, unplugging and plugging in one of the ports causes
> it to grab the next sd* device name.  As this is repeated, the number of deleted
> block devices multipathd holds on to grows, along with the number of unhappy
> rdac checkers.  As I said before, it takes a 'kill -9' to stop multipathd, and
> subsequent plugging ins choose sd* names that were previously used but were held
> onto as (deleted) by multipathd.
> 
> However, this behavior is not seen when multipathd is not running.  When the
> port is unplugged, the /dev/sd* device disappears, and when it is plugged back
> in, it takes the same name it had before (I assume it's just taking the lowest
> name, and its old name has been freed) cleanly, with no call traces or anything.
> 
> Any ideas on how to correct this behavior?
> 
Hmm. multipathd really should react to the 'remove' events for sdX.
Checking ...

Looks as if it does. And it even is supposed to stop the path checker.

Care to run multipathd with full debugging (ie -v 4) and post the output?
My guess is that somehow the path checker is not stopped and the fd is kept
open, so that the device is not released properly.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: multipath-tools causes path to come back as different block device

[Guido Guenther]

Hi Brian,
On Thu, Jul 19, 2007 at 03:54:51PM -0700, Brian De Wolf wrote:
> I've been testing multipath-tool's rdac capability with a qla2xxx HBA and an IBM
> DS4800 some more and I've hit another stumbling block.  When I test unplugging
> one of the HBA ports and plugging it back in with multipath running, it seems to
> cause bad things to happen.  Here is what the syslog looks like (note:  sdb is a
> path, sdd is initially unused, and sde is the second path):
I'm seeing the same and send a report to Christophe about this just
yesterday, it doesn't seem to be a driver issue since iSCSI is affected
as well.
Cheers,
 -- Guido

Re: multipath-tools causes path to come back as different block device

[Guido Guenther]

Hi Hannes,
On Fri, Jul 20, 2007 at 09:24:15AM +0200, Hannes Reinecke wrote:
> Hmm. multipathd really should react to the 'remove' events for sdX.
> Checking ...
> 
> Looks as if it does. And it even is supposed to stop the path checker.
> 
> Care to run multipathd with full debugging (ie -v 4) and post the output?
> My guess is that somehow the path checker is not stopped and the fd is kept
> open, so that the device is not released properly.
This even happens with no multipathd running on a Clariion with qla2xx.
So multipathd can't be at fault here, can it? Also with multipathd
running the device nodes in /dev/ and the sysfs nodes in /sys/block get
removed properly (at least it looks like to me). Any hints where else to
start digging?
Cheers,
 -- Guido

Re: multipath-tools causes path to come back as different block device

[Hannes Reinecke]

Guido Guenther wrote:
> Hi Hannes,
> On Fri, Jul 20, 2007 at 09:24:15AM +0200, Hannes Reinecke wrote:
>> Hmm. multipathd really should react to the 'remove' events for sdX.
>> Checking ...
>>
>> Looks as if it does. And it even is supposed to stop the path checker.
>>
>> Care to run multipathd with full debugging (ie -v 4) and post the output?
>> My guess is that somehow the path checker is not stopped and the fd is kept
>> open, so that the device is not released properly.
> This even happens with no multipathd running on a Clariion with qla2xx.
> So multipathd can't be at fault here, can it? Also with multipathd
> running the device nodes in /dev/ and the sysfs nodes in /sys/block get
> removed properly (at least it looks like to me). Any hints where else to
> start digging?
Removing from /dev and /sys in not sufficient, sadly.
The memory is only released after the last reference has gone.
So all fd's have to be closed (ie multipathd and the path checkers have
to have this path disabled) and no device-mapper table must reference it.

So easiest way is infact to have multipathd run with -v 4, as this will
tell you exactly if multipathd has stopped the path checker.
The device-mapper tables can be checked manually with dmsetup.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: multipath-tools causes path to come back as different block device

[Brian De Wolf]

Hannes Reinecke wrote:
> Hmm. multipathd really should react to the 'remove' events for sdX.
> Checking ...
> 
> Looks as if it does. And it even is supposed to stop the path checker.
> 
> Care to run multipathd with full debugging (ie -v 4) and post the output?
> My guess is that somehow the path checker is not stopped and the fd is kept
> open, so that the device is not released properly.
> 
> Cheers,
> 
> Hannes

Here's the log, as requested:

Jul 20 09:12:59 jimbo kernel: qla2xxx 0000:02:01.1: LOOP DOWN detected (2).
Jul 20 09:12:59 jimbo multipathd: tick
Jul 20 09:13:00 jimbo multipathd: tick
Jul 20 09:13:01 jimbo multipathd: tick
Jul 20 09:13:05 jimbo kernel: rport-4:0-0: blocked FC remote port time out:
removing target and saving binding
Jul 20 09:13:05 jimbo multipathd: sdd: rdac checker reports path is down
Jul 20 09:13:05 jimbo multipathd: checker failed path 8:48 in map test
Jul 20 09:13:05 jimbo multipathd: test: remaining active paths: 1
Jul 20 09:13:05 jimbo kernel: device-mapper: multipath: Failing path 8:48.
Jul 20 09:13:05 jimbo kernel: sd 4:0:0:0: [sdd] Synchronizing SCSI cache
Jul 20 09:13:05 jimbo kernel: sd 4:0:0:0: [sdd] Result: hostbyte=0x01
driverbyte=0x00
Jul 20 09:13:05 jimbo multipathd: test: devmap event #5
Jul 20 09:13:05 jimbo multipathd: 8:16: delay next check 20s
Jul 20 09:13:05 jimbo multipathd: path prio refresh
Jul 20 09:13:05 jimbo multipathd: sdb: mask = 0x8
Jul 20 09:13:05 jimbo multipathd: sdb: prio = 1
Jul 20 09:13:05 jimbo multipathd: test: switch to path group #2
Jul 20 09:13:05 jimbo multipathd: test: discover
Jul 20 09:13:05 jimbo multipathd: *word = 0, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = rdac, len = 4
Jul 20 09:13:05 jimbo multipathd: *word = 2, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 2, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 8:48, len = 4
Jul 20 09:13:05 jimbo multipathd: *word = 1000, len = 4
Jul 20 09:13:05 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 8:16, len = 4
Jul 20 09:13:05 jimbo multipathd: *word = 1000, len = 4
Jul 20 09:13:05 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 0, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 2, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = E, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 0, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = F, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = E, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 0, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = A, len = 1
Jul 20 09:13:05 jimbo multipathd: *word = 0, len = 1
Jul 20 09:13:05 jimbo multipathd: test: rr_weight = 1 (internal default)
Jul 20 09:13:05 jimbo multipathd: test: pgfailback = -2 (LUN setting)
Jul 20 09:13:05 jimbo multipathd: test: no_path_retry = NONE (internal default)
Jul 20 09:13:05 jimbo multipathd: pg_timeout = NONE (internal default)
Jul 20 09:13:05 jimbo multipathd: uevent 'remove' from '/class/scsi_device/4:0:0:0'
Jul 20 09:13:05 jimbo multipathd: UDEV_LOG=3
Jul 20 09:13:05 jimbo multipathd: ACTION=remove
Jul 20 09:13:05 jimbo multipathd: DEVPATH=/class/scsi_device/4:0:0:0
Jul 20 09:13:05 jimbo multipathd: SUBSYSTEM=scsi_device
Jul 20 09:13:05 jimbo multipathd: SEQNUM=944
Jul 20 09:13:05 jimbo multipathd:
PHYSDEVPATH=/devices/pci0000:00/0000:00:02.0/0000:02:01.1/host4/rport-4:0-0/target4:0:0/4:0:0:0
Jul 20 09:13:05 jimbo multipathd: PHYSDEVBUS=scsi
Jul 20 09:13:05 jimbo multipathd: PHYSDEVDRIVER=sd
Jul 20 09:13:05 jimbo multipathd: UDEVD_EVENT=1
Jul 20 09:13:05 jimbo multipathd: IN_HOTPLUG=1
Jul 20 09:13:05 jimbo multipathd: discard event on /class/scsi_device/4:0:0:0
Jul 20 09:13:05 jimbo multipathd: uevent 'remove' from '/class/scsi_disk/4:0:0:0'
Jul 20 09:13:05 jimbo multipathd: UDEV_LOG=3
Jul 20 09:13:05 jimbo multipathd: ACTION=remove
Jul 20 09:13:05 jimbo multipathd: DEVPATH=/class/scsi_disk/4:0:0:0
Jul 20 09:13:05 jimbo multipathd: SUBSYSTEM=scsi_disk
Jul 20 09:13:05 jimbo multipathd: SEQNUM=945
Jul 20 09:13:05 jimbo multipathd:
PHYSDEVPATH=/devices/pci0000:00/0000:00:02.0/0000:02:01.1/host4/rport-4:0-0/target4:0:0/4:0:0:0
Jul 20 09:13:05 jimbo multipathd: PHYSDEVBUS=scsi
Jul 20 09:13:05 jimbo multipathd: PHYSDEVDRIVER=sd
Jul 20 09:13:05 jimbo multipathd: UDEVD_EVENT=1
Jul 20 09:13:05 jimbo multipathd: IN_HOTPLUG=1
Jul 20 09:13:05 jimbo multipathd: discard event on /class/scsi_disk/4:0:0:0
Jul 20 09:13:05 jimbo multipathd: uevent 'remove' from '/block/sdd/sdd1'
Jul 20 09:13:05 jimbo multipathd: UDEV_LOG=3
Jul 20 09:13:05 jimbo multipathd: ACTION=remove
Jul 20 09:13:05 jimbo multipathd: DEVPATH=/block/sdd/sdd1
Jul 20 09:13:05 jimbo multipathd: SUBSYSTEM=block
Jul 20 09:13:05 jimbo multipathd: SEQNUM=946
Jul 20 09:13:05 jimbo multipathd: MINOR=49
Jul 20 09:13:05 jimbo multipathd: MAJOR=8
Jul 20 09:13:05 jimbo multipathd:
PHYSDEVPATH=/devices/pci0000:00/0000:00:02.0/0000:02:01.1/host4/rport-4:0-0/target4:0:0/4:0:0:0
Jul 20 09:13:05 jimbo multipathd: PHYSDEVBUS=scsi
Jul 20 09:13:05 jimbo multipathd: PHYSDEVDRIVER=sd
Jul 20 09:13:05 jimbo multipathd: UDEVD_EVENT=1
Jul 20 09:13:05 jimbo multipathd: IN_HOTPLUG=1
Jul 20 09:13:05 jimbo multipathd: ID_VENDOR=IBM
Jul 20 09:13:05 jimbo multipathd: ID_MODEL=1815_FAStT
Jul 20 09:13:05 jimbo multipathd: ID_REVISION=0914
Jul 20 09:13:05 jimbo multipathd: ID_SERIAL=3600a0b80001199100000a624468e6438
Jul 20 09:13:05 jimbo multipathd: ID_SERIAL_SHORT=600a0b80001199100000a624468e6438
Jul 20 09:13:05 jimbo multipathd: ID_TYPE=disk
Jul 20 09:13:05 jimbo multipathd: ID_BUS=scsi
Jul 20 09:13:05 jimbo multipathd:
ID_PATH=pci-0000:02:01.1-fc-0x202700a0b8119910:0x0000000000000000
Jul 20 09:13:05 jimbo multipathd: ID_FS_USAGE=filesystem
Jul 20 09:13:05 jimbo multipathd: ID_FS_TYPE=ext3
Jul 20 09:13:05 jimbo multipathd: ID_FS_VERSION=1.0
Jul 20 09:13:05 jimbo multipathd: ID_FS_UUID=8fe0f813-4d2b-4ed1-9b67-ba8805a37561
Jul 20 09:13:05 jimbo multipathd: ID_FS_LABEL=
Jul 20 09:13:05 jimbo multipathd: ID_FS_LABEL_SAFE=
Jul 20 09:13:05 jimbo multipathd:
DEVLINKS=/dev/disk/by-id/scsi-3600a0b80001199100000a624468e6438-part1
/dev/disk/by-path/pci-0000:02:01.1-fc-0x202700a0b8119
910:
Jul 20 09:13:05 jimbo multipathd: DEVNAME=/dev/sdd1
Jul 20 09:13:05 jimbo multipathd: discard event on /block/sdd/sdd1
Jul 20 09:13:05 jimbo multipathd: uevent 'remove' from
'/devices/pci0000:00/0000:00:02.0/0000:02:01.1/host4/rport-4:0-0/target4:0:0/4:0:0:0'
Jul 20 09:13:05 jimbo multipathd: UDEV_LOG=3
Jul 20 09:13:05 jimbo multipathd: ACTION=remove
Jul 20 09:13:05 jimbo multipathd:
DEVPATH=/devices/pci0000:00/0000:00:02.0/0000:02:01.1/host4/rport-4:0-0/target4:0:0/4:0:0:0
Jul 20 09:13:05 jimbo multipathd: SUBSYSTEM=scsi
Jul 20 09:13:05 jimbo multipathd: SEQNUM=948
Jul 20 09:13:05 jimbo multipathd: PHYSDEVBUS=scsi
Jul 20 09:13:05 jimbo multipathd: MODALIAS=scsi:t-0x00
Jul 20 09:13:05 jimbo multipathd: UDEVD_EVENT=1
Jul 20 09:13:05 jimbo multipathd: IN_HOTPLUG=1
Jul 20 09:13:05 jimbo multipathd: discard event on
/devices/pci0000:00/0000:00:02.0/0000:02:01.1/host4/rport-4:0-0/target4:0:0/4:0:0:0
Jul 20 09:13:05 jimbo multipathd: uevent 'remove' from '/block/sdd'
Jul 20 09:13:05 jimbo multipathd: UDEV_LOG=3
Jul 20 09:13:05 jimbo multipathd: ACTION=remove
Jul 20 09:13:05 jimbo multipathd: DEVPATH=/block/sdd
Jul 20 09:13:05 jimbo multipathd: SUBSYSTEM=block
Jul 20 09:13:05 jimbo multipathd: SEQNUM=947
Jul 20 09:13:05 jimbo multipathd: MINOR=48
Jul 20 09:13:05 jimbo multipathd: MAJOR=8
Jul 20 09:13:05 jimbo multipathd:
PHYSDEVPATH=/devices/pci0000:00/0000:00:02.0/0000:02:01.1/host4/rport-4:0-0/target4:0:0/4:0:0:0
Jul 20 09:13:05 jimbo multipathd: PHYSDEVBUS=scsi
Jul 20 09:13:05 jimbo multipathd: PHYSDEVDRIVER=sd
Jul 20 09:13:05 jimbo multipathd: UDEVD_EVENT=1
Jul 20 09:13:05 jimbo multipathd: IN_HOTPLUG=1
Jul 20 09:13:05 jimbo multipathd: ID_VENDOR=IBM
Jul 20 09:13:05 jimbo multipathd: ID_MODEL=1815_FAStT
Jul 20 09:13:05 jimbo multipathd: ID_REVISION=0914
Jul 20 09:13:05 jimbo multipathd: ID_SERIAL=3600a0b80001199100000a624468e6438
Jul 20 09:13:05 jimbo multipathd: ID_SERIAL_SHORT=600a0b80001199100000a624468e6438
Jul 20 09:13:05 jimbo multipathd: ID_TYPE=disk
Jul 20 09:13:05 jimbo multipathd: ID_BUS=scsi
Jul 20 09:13:05 jimbo multipathd:
ID_PATH=pci-0000:02:01.1-fc-0x202700a0b8119910:0x0000000000000000
Jul 20 09:13:05 jimbo multipathd:
DEVLINKS=/dev/disk/by-id/scsi-3600a0b80001199100000a624468e6438
/dev/disk/by-path/pci-0000:02:01.1-fc-0x202700a0b8119910:0x
0000
Jul 20 09:13:05 jimbo multipathd: DEVNAME=/dev/sdd
Jul 20 09:13:06 jimbo multipathd: tick
Jul 20 09:13:06 jimbo multipathd: test: devmap event #6
Jul 20 09:13:06 jimbo multipathd: test: discover
Jul 20 09:13:06 jimbo multipathd: *word = 0, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = rdac, len = 4
Jul 20 09:13:06 jimbo multipathd: *word = 2, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 2, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 8:48, len = 4
Jul 20 09:13:06 jimbo multipathd: *word = 1000, len = 4
Jul 20 09:13:06 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 8:16, len = 4
Jul 20 09:13:06 jimbo multipathd: *word = 1000, len = 4
Jul 20 09:13:06 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 0, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 2, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = E, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 0, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = F, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = E, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 1, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 0, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = A, len = 1
Jul 20 09:13:06 jimbo multipathd: *word = 0, len = 1
Jul 20 09:13:06 jimbo multipathd: test: rr_weight = 1 (internal default)
Jul 20 09:13:06 jimbo multipathd: test: pgfailback = -2 (LUN setting)
Jul 20 09:13:06 jimbo multipathd: test: no_path_retry = NONE (internal default)
Jul 20 09:13:06 jimbo multipathd: pg_timeout = NONE (internal default)
Jul 20 09:13:07 jimbo multipathd: tick
Jul 20 09:13:07 jimbo multipathd: map garbage collection
Jul 20 09:13:08 jimbo multipathd: tick
Jul 20 09:13:09 jimbo multipathd: tick
Jul 20 09:13:10 jimbo multipathd: tick
Jul 20 09:13:10 jimbo kernel: scsi 4:0:0:0: rejecting I/O to dead device
Jul 20 09:13:10 jimbo multipathd: sdd: rdac checker reports path is down
Jul 20 09:13:10 jimbo multipathd: path prio refresh
Jul 20 09:13:10 jimbo multipathd: sdd: mask = 0x8
Jul 20 09:13:11 jimbo multipathd: tick
...

After that, the last five lines keep repeating until it's killed.

Re: multipath-tools causes path to come back as different block device

[Guido Guenther]

Hi Hannes,
On Fri, Jul 20, 2007 at 04:40:11PM +0200, Hannes Reinecke wrote:
> Removing from /dev and /sys in not sufficient, sadly.
> The memory is only released after the last reference has gone.
> So all fd's have to be closed (ie multipathd and the path checkers have
> to have this path disabled) and no device-mapper table must reference it.
Knowing this, the problem is much easier to spot...

> So easiest way is infact to have multipathd run with -v 4, as this will
> tell you exactly if multipathd has stopped the path checker.
> The device-mapper tables can be checked manually with dmsetup.
...it's in multpathd/main.c. The sysfs device is already gone when we
get the remove event. This patch makes it obvious:

diff --git a/multipathd/main.c b/multipathd/main.c
index 5f98c33..00890d7 100644
--- a/multipathd/main.c
+++ b/multipathd/main.c
@@ -635,8 +635,10 @@ uev_trigger (struct uevent * uev, void * trigger_data)
 		return 0;
 
 	sysdev = sysfs_device_get(uev->devpath);
-	if(!sysdev)
-		return 0;	
+	if (!sysdev) {
+		condlog(4, "Devpath '%s' of uevent '%s' vanished", uev->devpath, uev->action);
+		return 0;
+	}
 
 	lock(vecs->lock);

Signed-Off-By: Guido Günther <agx@sigxcpu.org>

The sysfs device is already gone, so sysfs_device_get returns 0 and we
never call uev_remove_path further down below. The check of the return
value was added by f1b1fca2ccbfd7d58350eb136105fdaf8aa4f59ca, which is
imho correct. Can we expect the sysfs node to stay around long enough? I
don't think so, so should we cache the sysfs_device structures somewhere
to use them on path removal? I could cook up a patch.
Cheers,
 -- Guido

[multipath 1/1] cache sysfs_devices

[-s]

From: Guido Guenther <agx@sigxcpu.org>

This also plugs a memory leak where we'd malloc space for the same sysfs device
over and over again for every processed uevent.
---
 libmultipath/sysfs.c |   47 +++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 39 insertions(+), 8 deletions(-)

diff --git a/libmultipath/sysfs.c b/libmultipath/sysfs.c
index 1fb5436..d8c65b2 100644
--- a/libmultipath/sysfs.c
+++ b/libmultipath/sysfs.c
@@ -45,6 +45,13 @@ struct sysfs_attr {
 	char value_local[NAME_SIZE];
 };
 
+/* list of sysfs devices */
+static LIST_HEAD(sysfs_dev_list);
+struct sysfs_dev {
+	struct list_head node;
+	struct sysfs_device dev;
+};
+
 int sysfs_init(char *path, size_t len)
 {
 	if (path) {
@@ -55,6 +62,7 @@ int sysfs_init(char *path, size_t len)
 	dbg("sysfs_path='%s'", sysfs_path);
 
 	INIT_LIST_HEAD(&attr_list);
+	INIT_LIST_HEAD(&sysfs_dev_list);
 	return 0;
 }
 
@@ -63,11 +71,17 @@ void sysfs_cleanup(void)
 	struct sysfs_attr *attr_loop;
 	struct sysfs_attr *attr_temp;
 
+	struct sysfs_dev *sysdev_loop;
+	struct sysfs_dev *sysdev_temp;
+
 	list_for_each_entry_safe(attr_loop, attr_temp, &attr_list, node) {
 		list_del(&attr_loop->node);
 		free(attr_loop);
 	}
 
+	list_for_each_entry_safe(sysdev_loop, sysdev_temp, &sysfs_dev_list, node) {
+		free(sysdev_loop);
+	}
 }
 
 void sysfs_device_set_values(struct sysfs_device *dev, const char *devpath,
@@ -140,7 +154,8 @@ struct sysfs_device *sysfs_device_get(const char *devpath)
 {
 	char path[PATH_SIZE];
 	char devpath_real[PATH_SIZE];
-	struct sysfs_device *dev;
+	struct sysfs_device *dev = NULL;
+	struct sysfs_dev *sysdev_loop, *sysdev;
 	struct stat statbuf;
 	char link_path[PATH_SIZE];
 	char link_target[PATH_SIZE];
@@ -155,7 +170,14 @@ struct sysfs_device *sysfs_device_get(const char *devpath)
 	strlcpy(path, sysfs_path, sizeof(path));
 	strlcat(path, devpath_real, sizeof(path));
 	if (lstat(path, &statbuf) != 0) {
+		/* if stat fails look in the cache */
 		dbg("stat '%s' failed: %s", path, strerror(errno));
+		list_for_each_entry(sysdev_loop, &sysfs_dev_list, node) {
+			if (strcmp(sysdev_loop->dev.devpath, devpath_real) == 0) {
+				dbg("found vanished dev in cache '%s'", sysdev_loop->dev.devpath);
+				return &sysdev_loop->dev;
+			}
+		}
 		return NULL;
 	}
 	if (S_ISLNK(statbuf.st_mode)) {
@@ -164,12 +186,22 @@ struct sysfs_device *sysfs_device_get(const char *devpath)
 
 	}
 
-	/* it is a new device */
-	dbg("new device '%s'", devpath_real);
-	dev = malloc(sizeof(struct sysfs_device));
-	if (dev == NULL)
-		return NULL;
-	memset(dev, 0x00, sizeof(struct sysfs_device));
+	list_for_each_entry(sysdev_loop, &sysfs_dev_list, node) {
+		if (strcmp(sysdev_loop->dev.devpath, devpath_real) == 0) {
+			dbg("found dev in cache '%s'", sysdev_loop->dev.devpath);
+				dev = &sysdev_loop->dev;
+		}
+	}
+	if(!dev) {
+		/* it is a new device */
+		dbg("new device '%s'", devpath_real);
+		sysdev = malloc(sizeof(struct sysfs_dev));
+		if (sysdev == NULL)
+			return NULL;
+		memset(sysdev, 0x00, sizeof(struct sysfs_dev));
+		list_add(&sysdev->node, &sysfs_dev_list);
+		dev = &sysdev->dev;
+	}
 
 	sysfs_device_set_values(dev, devpath_real, NULL, NULL);
 
@@ -226,7 +258,6 @@ struct sysfs_device *sysfs_device_get(const char *devpath)
 		if (pos != NULL)
 			strlcpy(dev->driver, &pos[1], sizeof(dev->driver));
 	}
-
 	return dev;
 }
 
-- 
1.5.2.4

Re: [multipath 1/1] cache sysfs_devices

[Guido Guenther]

I give up on git-send-email - it always fools me. Nevertheless this one
fixes the described bug of paths coming back as different block
devices:

Keep a list of sysfs devices for sysfs_device_get() so uev_trigger() can look
up the necessary information for proper path removal in case of a 'remove'
uevent - the sysfs files in the filesystem might be long gone at this point.

This also plugs a memory leak where we'd malloc space for the same sysfs device
over and over again for every processed uevent.

Signed-off-by: Guido Guenther <agx@sigxcpu.org>
---
 libmultipath/sysfs.c |   47 +++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 39 insertions(+), 8 deletions(-)

diff --git a/libmultipath/sysfs.c b/libmultipath/sysfs.c
index 1fb5436..d8c65b2 100644
--- a/libmultipath/sysfs.c
+++ b/libmultipath/sysfs.c
@@ -45,6 +45,13 @@ struct sysfs_attr {
 	char value_local[NAME_SIZE];
 };
 
+/* list of sysfs devices */
+static LIST_HEAD(sysfs_dev_list);
+struct sysfs_dev {
+	struct list_head node;
+	struct sysfs_device dev;
+};
+
 int sysfs_init(char *path, size_t len)
 {
 	if (path) {
@@ -55,6 +62,7 @@ int sysfs_init(char *path, size_t len)
 	dbg("sysfs_path='%s'", sysfs_path);
 
 	INIT_LIST_HEAD(&attr_list);
+	INIT_LIST_HEAD(&sysfs_dev_list);
 	return 0;
 }
 
@@ -63,11 +71,17 @@ void sysfs_cleanup(void)
 	struct sysfs_attr *attr_loop;
 	struct sysfs_attr *attr_temp;
 
+	struct sysfs_dev *sysdev_loop;
+	struct sysfs_dev *sysdev_temp;
+
 	list_for_each_entry_safe(attr_loop, attr_temp, &attr_list, node) {
 		list_del(&attr_loop->node);
 		free(attr_loop);
 	}
 
+	list_for_each_entry_safe(sysdev_loop, sysdev_temp, &sysfs_dev_list, node) {
+		free(sysdev_loop);
+	}
 }
 
 void sysfs_device_set_values(struct sysfs_device *dev, const char *devpath,
@@ -140,7 +154,8 @@ struct sysfs_device *sysfs_device_get(const char *devpath)
 {
 	char path[PATH_SIZE];
 	char devpath_real[PATH_SIZE];
-	struct sysfs_device *dev;
+	struct sysfs_device *dev = NULL;
+	struct sysfs_dev *sysdev_loop, *sysdev;
 	struct stat statbuf;
 	char link_path[PATH_SIZE];
 	char link_target[PATH_SIZE];
@@ -155,7 +170,14 @@ struct sysfs_device *sysfs_device_get(const char *devpath)
 	strlcpy(path, sysfs_path, sizeof(path));
 	strlcat(path, devpath_real, sizeof(path));
 	if (lstat(path, &statbuf) != 0) {
+		/* if stat fails look in the cache */
 		dbg("stat '%s' failed: %s", path, strerror(errno));
+		list_for_each_entry(sysdev_loop, &sysfs_dev_list, node) {
+			if (strcmp(sysdev_loop->dev.devpath, devpath_real) == 0) {
+				dbg("found vanished dev in cache '%s'", sysdev_loop->dev.devpath);
+				return &sysdev_loop->dev;
+			}
+		}
 		return NULL;
 	}
 	if (S_ISLNK(statbuf.st_mode)) {
@@ -164,12 +186,22 @@ struct sysfs_device *sysfs_device_get(const char *devpath)
 
 	}
 
-	/* it is a new device */
-	dbg("new device '%s'", devpath_real);
-	dev = malloc(sizeof(struct sysfs_device));
-	if (dev == NULL)
-		return NULL;
-	memset(dev, 0x00, sizeof(struct sysfs_device));
+	list_for_each_entry(sysdev_loop, &sysfs_dev_list, node) {
+		if (strcmp(sysdev_loop->dev.devpath, devpath_real) == 0) {
+			dbg("found dev in cache '%s'", sysdev_loop->dev.devpath);
+				dev = &sysdev_loop->dev;
+		}
+	}
+	if(!dev) {
+		/* it is a new device */
+		dbg("new device '%s'", devpath_real);
+		sysdev = malloc(sizeof(struct sysfs_dev));
+		if (sysdev == NULL)
+			return NULL;
+		memset(sysdev, 0x00, sizeof(struct sysfs_dev));
+		list_add(&sysdev->node, &sysfs_dev_list);
+		dev = &sysdev->dev;
+	}
 
 	sysfs_device_set_values(dev, devpath_real, NULL, NULL);
 
@@ -226,7 +258,6 @@ struct sysfs_device *sysfs_device_get(const char *devpath)
 		if (pos != NULL)
 			strlcpy(dev->driver, &pos[1], sizeof(dev->driver));
 	}
-
 	return dev;
 }
 
-- 
1.5.2.4

Re: [multipath 1/1] cache sysfs_devices

[Christophe Varoqui]

Le vendredi 20 juillet 2007 à 23:03 +0200, Guido Guenther a écrit :
> I give up on git-send-email - it always fools me. Nevertheless this one
> fixes the described bug of paths coming back as different block
> devices:
> 
Merged, thanks.

Would "git-show --pretty=email <sha>" be what you need ?

Re: Re: [multipath 1/1] cache sysfs_devices

[Hannes Reinecke]

Guido Guenther wrote:
> I give up on git-send-email - it always fools me. Nevertheless this one
> fixes the described bug of paths coming back as different block
> devices:
> 
> Keep a list of sysfs devices for sysfs_device_get() so uev_trigger() can look
> up the necessary information for proper path removal in case of a 'remove'
> uevent - the sysfs files in the filesystem might be long gone at this point.
> 
> This also plugs a memory leak where we'd malloc space for the same sysfs device
> over and over again for every processed uevent.
> 
Hmm. But now we're running into the opposite trap: memory for a block device once
existing will never be freed. So over time we're likely to become a memory hog.

Better it would be to remove the sysfs device from the cache once we're done
with it.

I'll cook up a patch.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: Re: [multipath 1/1] cache sysfs_devices

[Guido Guenther]

On Tue, Jul 24, 2007 at 08:35:16AM +0200, Hannes Reinecke wrote:
> Guido Guenther wrote:
> > I give up on git-send-email - it always fools me. Nevertheless this one
> > fixes the described bug of paths coming back as different block
> > devices:
> > 
> > Keep a list of sysfs devices for sysfs_device_get() so uev_trigger() can look
> > up the necessary information for proper path removal in case of a 'remove'
> > uevent - the sysfs files in the filesystem might be long gone at this point.
> > 
> > This also plugs a memory leak where we'd malloc space for the same sysfs device
> > over and over again for every processed uevent.
> > 
> Hmm. But now we're running into the opposite trap: memory for a block device once
> existing will never be freed. So over time we're likely to become a memory hog.
So far we did not free any memory _and_ we would end up allocating memory
for every path that comes back up over and over again.

> Better it would be to remove the sysfs device from the cache once we're done
> with it.
Fair enough, we won't need the information then anyway.
Thanks,
 -- Guido