| Message ID | CABr-GneD2JwJ5YHx9n5C42zeiivF5gg0hcg_mab1EuwucfOp0Q@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On 05/04/2014 01:34 AM, Christophe Varoqui wrote: > It seems sg_persist is doing an "open rw => close" for --in commands, > causing a kernel change-event. Yep. Look for 'watch' in the udev rules, that's precisely what it's doing. (Bloody annoying if you ask me. Generally I recommend to remove that thing from the rules). Cheers, Hannes
Dne 4.5.2014 18:54, Hannes Reinecke napsal(a): > On 05/04/2014 01:34 AM, Christophe Varoqui wrote: >> It seems sg_persist is doing an "open rw => close" for --in commands, >> causing a kernel change-event. > Yep. > > Look for 'watch' in the udev rules, that's precisely what it's doing. > > (Bloody annoying if you ask me. Generally I recommend to remove that thing > from the rules). When watch rule is disabled/removed in udev rules - your udev db becomes invalid when i.e. you run command like 'mkfs' - since the udev db will not be updated to list information about newly formatted filesystem. Of course there are many cases where disabling watch rule makes sense (i.e. you export lots of disks to virtual guests) - but unless you are familiar with udev and you know what you are doing - think twice before disabling. Zdenek -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
--- 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;
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 ? } Regards, Christophe Varoqui www.opensvc.com On Sat, May 3, 2014 at 10:12 PM, Christophe Varoqui < christophe.varoqui@opensvc.com> 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/sdbh > PR generation=0x0, there are NO registered reservation keys > > 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) > ACTION=change > DEVNAME=/dev/sdbh > > 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 > DEVTYPE=disk > MAJOR=67 > MINOR=176 > SEQNUM=261605 > SUBSYSTEM=block > > Every 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 $devpath > 2/ udisks-lvm-pv-export $pv_uuid > > > 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 ? > > Best regards, > Christophe Varoqui > www.opensvc.com > > -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel