From patchwork Sat May 3 23:34:20 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christophe Varoqui X-Patchwork-Id: 4106921 Return-Path: X-Original-To: patchwork-dm-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id EB6A29F271 for ; Sat, 3 May 2014 23:38:48 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 06F552021A for ; Sat, 3 May 2014 23:38:48 +0000 (UTC) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) by mail.kernel.org (Postfix) with ESMTP id CFF3E20212 for ; Sat, 3 May 2014 23:38:46 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s43NYNA5007255; Sat, 3 May 2014 19:34:25 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s43NYMrB004463 for ; Sat, 3 May 2014 19:34:22 -0400 Received: from mx1.redhat.com (ext-mx13.extmail.prod.ext.phx2.redhat.com [10.5.110.18]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s43NYLhR015757 for ; Sat, 3 May 2014 19:34:22 -0400 Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s43NYK6K007606 for ; Sat, 3 May 2014 19:34:20 -0400 Received: by mail-ie0-f177.google.com with SMTP id rp18so6364955iec.8 for ; Sat, 03 May 2014 16:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=jj0l/me90zqqayXT82sEuhuPUKedf2m9gYGAvzVmZZk=; b=RFw5Roq+gMTJ7F+1b9XG/HSpRhuAWAg8JMOnkgJzhtf8PG5c71z8fjuPes5ecMd9wf sVvw1Cqpntj3It6lnX40pZqWTSDdVdYKJCPNjqQwWiVBDE9lAJh1CgLbrF7dpOzVcfbb ZF9jAS5FnUGEcCrboDwMweAomIsSvYnH6OAWZ5Q9ulXMf98cUR/edcXFrfMM9CZ6Nm0v SgslPfEbM9R/TujXXMc07X4EwnBSCrm4Ayc2URqKyD7yiqo9nqATtlgkJ+7duwh6Vpaf fXWzyUKvmLZPqTwb2uQyn6XAGH2RfTpcS7p6mwn7rHYpxZO9k+P7XH6f9nmDutnqaKPF m/4w== MIME-Version: 1.0 X-Received: by 10.50.60.72 with SMTP id f8mr14295703igr.20.1399160060094; Sat, 03 May 2014 16:34:20 -0700 (PDT) Received: by 10.64.230.198 with HTTP; Sat, 3 May 2014 16:34:20 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 May 2014 01:34:20 +0200 X-Google-Sender-Auth: q61AgufRq07RuKLSQSQf75SDcwE Message-ID: From: Christophe Varoqui To: device-mapper development , dgilbert@interlog.com X-RedHat-Spam-Score: -2.698 (BAYES_00, DCC_REPUT_13_19, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, SPF_PASS, URIBL_BLOCKED) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Scanned-By: MIMEDefang 2.68 on 10.5.110.18 X-loop: dm-devel@redhat.com Subject: Re: [dm-devel] sg_persist triggers block kernel event ??? X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk Reply-To: device-mapper development List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- 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;