It seems sg_persist is doing an "open rw => close" for --in commands, causing a kernel change-event.
I can not verify at the moment if the following patch would work ... comments ?
--- sg_persist.c.orig 2014-05-04 01:10:01.987981956 +0200
+++ sg_persist.c 2014-05-04 01:15:34.880008000 +0200
@@ -1029,6 +1029,8 @@
struct sg_simple_inquiry_resp inq_resp;
const char * cp;
struct opts_t opts;
+ int omode = 0;
+ const char *omode_desc = NULL;
memset(&opts, 0, sizeof(opts));
opts.prin = 1;
@@ -1292,10 +1294,18 @@
sg_cmds_close_device(sg_fd);
}
- if ((sg_fd = sg_cmds_open_device(device_name, 0 /* rw */,
+ if (opts.prin) {
+ omode = 1;
+ omode_desc = "ro";
+ } else {
+ omode = 0;
+ omode_desc = "rw";
+ }
+
+ if ((sg_fd = sg_cmds_open_device(device_name, omode,
opts.verbose)) < 0) {
- pr2serr("sg_persist: error opening file (rw): %s: %s\n", device_name,
- safe_strerror(-sg_fd));
+ pr2serr("sg_persist: error opening file (%s): %s: %s\n", omode_desc,
+ device_name, safe_strerror(-sg_fd));
return SG_LIB_FILE_ERROR;
}
Regards,
Christophe Varoqui
On Sat, May 3, 2014 at 10:12 PM, Christophe Varoqui <christophe.varoqui@xxxxxxxxxxx> wrote:
Hi list,I observe this on a debian 7.5 server with a udevadm monitor running in the background :# sg_persist -n -k /dev/sdbhPR generation=0x0, there are NO registered reservation keysKERNEL[448809.342461] change /devices/pci0000:20/0000:20:02.2/0000:24:00.0/host0/rport-0:0-3/target0:0:1/0:0:1:12/block/sdbh (block)ACTION="">DEVNAME=/dev/sdbhDEVPATH=/devices/pci0000:20/0000:20:02.2/0000:24:00.0/host0/rport-0:0-3/target0:0:1/0:0:1:12/block/sdbhDEVTYPE=diskMAJOR=67MINOR=176SEQNUM=261605SUBSYSTEM=blockEvery sg_persist command, with any options, trigger events.On this server with more than 200 scsi devices, each receiving one read-key and one read-reservation every 10 minutes, this triggers quite a eavy load caused by 2 udev triggers :1/ multipath -v0 $devpath2/ udisks-lvm-pv-export $pv_uuidQuestion is, is it normal for a "--in" sg_persist command to trigger a change event on the scsi device ? If not, what we can do about it ?Best regards,Christophe Varoqui
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
- Follow-Ups:
- Re: sg_persist triggers block kernel event ???
- From: Hannes Reinecke
- Re: sg_persist triggers block kernel event ???
- References:
- sg_persist triggers block kernel event ???
- From: Christophe Varoqui
- sg_persist triggers block kernel event ???
- Prev by Date: Re: sg_persist triggers block kernel event ???
- Next by Date: Re: sg_persist triggers block kernel event ???
- Previous by thread: Re: sg_persist triggers block kernel event ???
- Next by thread: Re: sg_persist triggers block kernel event ???
- Index(es):