Re: sg_persist triggers block kernel event ???

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Indeed, I'd rather let udev do its work on legitimate device changes. Problem is, this change event caused by sg_persist prin commands in not legitimate : no device change can be caused by interrogating the disk pr status.

Doug informed me newer kernels accept prin commands inside a open-ro=>close sequence, which I now verified by testing with the patch I sent ... but older kernels do not. My patch is thus not backward compatible as-is.

Any advice on how to treat this backward-compatibility issue ?

For information, here's a more recent version of the patch I sent to Doug earlier to address not-Linux platform behaviour stability :

--- sg_persist.c.orig 2014-05-04 01:10:01.987981956 +0200
+++ sg_persist.c 2014-05-04 08:41:29.482017943 +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 = "rw";
 
     memset(&opts, 0, sizeof(opts));
     opts.prin = 1;
@@ -1292,10 +1294,17 @@
         sg_cmds_close_device(sg_fd);
     }
 
-    if ((sg_fd = sg_cmds_open_device(device_name, 0 /* rw */,
+#ifdef SG_LIB_LINUX
+    if (opts.prin) {
+        omode = 1;
+        omode_desc = "ro";
+    }
+#endif
+
+    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
www.opensvc.com



On Sun, May 4, 2014 at 7:23 PM, Zdenek Kabelac <zkabelac@xxxxxxxxxx> wrote:
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux