Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp6727941ybn; Mon, 30 Sep 2019 02:48:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqx6t8TMhOLAI7UWUh95zPpJph+bWXVAVVWSPRkUgg4d6FIRIx1qVvr1yrgdXRufCi1O0dFV X-Received: by 2002:a50:d49c:: with SMTP id s28mr18746399edi.101.1569836910969; Mon, 30 Sep 2019 02:48:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569836910; cv=none; d=google.com; s=arc-20160816; b=Qd99qY8U2Y8zu0ySPgXPEYPUBa7Lz/lP74QWmpCaPw19m1pHZxXJDuCMn0KKaBSwRL XTA1S5eXhi+N2MDBHZQ/h+n6F2o2AsltD66o4AHo9HKK0bI1lpNrpGJ61jFz5alUcrbp NSYnxtKdMPMZioAP9VsqMpfpgje8jXg3diwhMlMQGfcqVGrk0ejITtbqwHuaTROO7zgD 7mHwi3qO0GsOUp7/62lXJP8Mv23yunp3HyNXyPOoxOeWTpdqcwPFzDmgIpZuUhxJtoef Gbbbs+5Hk5D8VKVZC6BfZAj8Zl3mBcZaLoFFvvVxQ+Mwkyfme7ES1lBOPewJ1Dc8JUKX UXcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=lYkE4NjPqOY8tfec+ocPjFEgv1TuvzxpNbqe7h7M+U4=; b=s/QIk3jMUdEZJ8fJLV6/CQqSonJeES54cU3Y9IVbR2WIuC92oi5KszqRm0VvJyuOb3 dX9UzeKT+bs3+3mJgRAEEWXKooiVVMMRFCL8iR9E4nHE16xFaT4lXwgCbkPnq4cKJW0h jdxjPl0AuBqgyZRS9Sg0TDa42kpbE8u/04FkwKKHfhIEorI4h+/MyqWhZVGVN74jo7MR KY7tUnrWduHhiVW37/IX0jTrg//6LDV48r48tabdFWkrkKTjxV7Gz3FzOZ9kex6TiCuH DW45PFftmlBVRunlPFir2PXH1LI5139p+E9Ihtiy6Y8gdY+7nLAsYXERwnXJQeV/OWuc 5GqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b16si6635250edb.341.2019.09.30.02.48.06; Mon, 30 Sep 2019 02:48:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728404AbfI3JqD (ORCPT + 99 others); Mon, 30 Sep 2019 05:46:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:52566 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726329AbfI3JqD (ORCPT ); Mon, 30 Sep 2019 05:46:03 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 974A3AC11; Mon, 30 Sep 2019 09:46:01 +0000 (UTC) Message-ID: Subject: Re: [PATCH] scsi: core: Log SCSI command age with errors From: Martin Wilck To: mgandhi@redhat.com, Laurence Oberman , linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org Cc: jejb@linux.ibm.com, martin.petersen@oracle.com Date: Mon, 30 Sep 2019 11:46:06 +0200 In-Reply-To: <31eb5bb6-ca4e-1c6c-3013-7d94ff49623d@redhat.com> References: <20190923060122.GA9603@machine1> <471732f03049a1528df1d144013d723041f0a419.camel@suse.de> <3a8ee584f9846fba94d98d0e6941fefdcbed5d71.camel@redhat.com> <31eb5bb6-ca4e-1c6c-3013-7d94ff49623d@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Milan, On Mon, 2019-09-30 at 14:35 +0530, Milan P. Gandhi wrote: > On 9/30/19 2:12 PM, Martin Wilck wrote: > > Wrt the enablement of the option on highly loaded systems, I'm not > > sure > > I understand. You need to enable SCSI logging anyway, don't you? > > By default we keep the SCSI debug logging disabled or am I missing > something? > > > Is it an issue to have to set 2 sysfs values rather than just one? > > The idea here is to capture the above debug data even without > any user interventions to change any sysfs entries or to enable > debug logging on busy, critical production systems. So, you're looking at the scsi_io_completion() code path. In my experience that isn't reliable for bug hunting because of the the message rate limiting. Therefore I prefer using SCSI logging MLCOMPLETE=1, where no rate limiting applies. But that's just a side note, it depends on the case what's more useful. Back to the cmd age output, IMO we're are on a thin line between capturing useful information and keeping the logs neat. As I already said, I'm not convinced that this information, as important it may be for the case(s) you're currently investigating, has the same generic degree of importance or usefulness as what's currently printed (the CDB and the sense data). But OTOH, that's just a gut feeling, and I can't claim to have the experience to make general statement on it. If noone else has issues with this being printed by default, I'm not going oppose it. > Also, we are not changing the existing text in SCSI command error > log, > but we are only adding one single word at the end of message. Ideally > the user scripts are written to grep specific pattern from the logs. > Since we are not replacing any existing text from the logs, the > scripts should still work with this change as well. You are certainly aware that such scripts don't necessarily conform to what kernel developers would consider "ideal" :-) But again, I just wanted to raise the issue; if noone else thinks it matters, fine with me. Thanks Martin