<div dir="ltr">It seems sg_persist is doing an "open rw => close" for --in commands, causing a kernel change-event.<div>I can not verify at the moment if the following patch would work ... comments ?</div><div>
<br></div><div><div>--- sg_persist.c.orig<span class="" style="white-space:pre">      </span>2014-05-04 01:10:01.987981956 +0200<br></div><div>+++ sg_persist.c<span class="" style="white-space:pre">      </span>2014-05-04 01:15:34.880008000 +0200</div>
<div>@@ -1029,6 +1029,8 @@</div><div>     struct sg_simple_inquiry_resp inq_resp;</div><div>     const char * cp;</div><div>     struct opts_t opts;</div><div>+    int omode = 0;</div><div>+    const char *omode_desc = NULL;</div>
<div> </div><div>     memset(&opts, 0, sizeof(opts));</div><div>     opts.prin = 1;</div><div>@@ -1292,10 +1294,18 @@</div><div>         sg_cmds_close_device(sg_fd);</div><div>     }</div><div> </div><div>-    if ((sg_fd = sg_cmds_open_device(device_name, 0 /* rw */,</div>
<div>+    if (opts.prin) {</div><div>+        omode = 1;</div><div>+        omode_desc = "ro";</div><div>+    } else {</div><div>+        omode = 0;</div><div>+        omode_desc = "rw";</div><div>+    }</div>
<div>+</div><div>+    if ((sg_fd = sg_cmds_open_device(device_name, omode,</div><div>                                      opts.verbose)) < 0) {</div><div>-        pr2serr("sg_persist: error opening file (rw): %s: %s\n", device_name,</div>
<div>-                safe_strerror(-sg_fd));</div><div>+        pr2serr("sg_persist: error opening file (%s): %s: %s\n", omode_desc,</div><div>+                device_name, safe_strerror(-sg_fd));</div><div>         return SG_LIB_FILE_ERROR;</div>
<div>     }</div><div> </div></div><div>Regards,</div><div>Christophe Varoqui</div><div><a href="http://www.opensvc.com">www.opensvc.com</a></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 3, 2014 at 10:12 PM, Christophe Varoqui <span dir="ltr"><<a href="mailto:christophe.varoqui@opensvc.com" target="_blank">christophe.varoqui@opensvc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi list,<div><br></div><div>I observe this on a debian 7.5 server with a udevadm monitor running in the background :</div>
<div><br></div><div><div># sg_persist -n -k /dev/sdbh</div><div>  PR generation=0x0, there are NO registered reservation keys</div>
<div><br></div><div>KERNEL[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)</div><div>ACTION=change</div><div>DEVNAME=/dev/sdbh</div><div>DEVPATH=/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</div>

<div>DEVTYPE=disk</div><div>MAJOR=67</div><div>MINOR=176</div><div>SEQNUM=261605</div><div>SUBSYSTEM=block</div></div><div><br></div><div>Every sg_persist command, with any options, trigger events.</div><div><br></div><div>

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 :</div><div><br></div><div>1/ multipath -v0 $devpath</div>

<div>2/ udisks-lvm-pv-export $pv_uuid</div><div><br></div><div><br></div><div>Question 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 ?</div>

<div><br></div><div>Best regards,</div><div>Christophe Varoqui</div><div><a href="http://www.opensvc.com" target="_blank">www.opensvc.com</a></div><div><br></div></div>
</blockquote></div><br></div>