[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101130225956.GA8882@redhat.com>
Date: Tue, 30 Nov 2010 17:59:56 -0500
From: Mike Snitzer <snitzer@...hat.com>
To: Hannes Reinecke <hare@...e.de>
Cc: "Jun'ichi Nomura" <j-nomura@...jp.nec.com>,
Kiyoshi Ueda <k-ueda@...jp.nec.com>, michaelc@...wisc.edu,
tytso@....edu, linux-scsi@...r.kernel.org, jaxboe@...ionio.com,
vst@...b.net, linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@....de>, linux-raid@...r.kernel.org,
linux-ide@...r.kernel.org,
device-mapper development <dm-devel@...hat.com>,
James.Bottomley@...e.de, Sergei Shtylyov <sshtylyov@...sta.com>,
konishi.ryusuke@....ntt.co.jp, linux-fsdevel@...r.kernel.org,
jack@...e.cz, rwheeler@...hat.com, swhiteho@...hat.com,
chris.mason@...cle.com, Tejun Heo <tj@...nel.org>
Subject: Re: training mpath to discern between SCSI errors
On Thu, Nov 18 2010 at 10:11pm -0500,
Malahal Naineni <malahal@...ibm.com> wrote:
> Hannes Reinecke [hare@...e.de] wrote:
> > > Also (although this might be a bit off topic from your patch),
> > > can we expand such a distinction to what should be logged?
> > > Currently, it's difficult to distinguish important SCSI/block errors
> > > and less important ones in kernel log.
> > > For example, when I get a link failure on sda, kernel prints something
> > > like below, regardless of whether the I/O is recovered by multipathing or not:
> > > end_request: I/O error, dev sda, sector XXXXX
> > >
> > Indeed, when using the above we could be modifying the above
> > message, eg by
> >
> > end_request: transport error, dev sda, sector XXXXX
> >
> > or
> >
> > end_request: target error, dev sda, sector XXXXX
> >
> > which would improve the output noticeable.
> >
> > > Setting REQ_QUIET in dm-multipath could mask the message
> > > but also other important ones in SCSI.
> > >
> > Hmm. Not sure about that, but I think the above modifications will
> > be useful already.
> >
> > I'll be sending an updated patch.
>
> Hannes, is there an updated version of this patch? It applied fine with
> Linus git tree with a minor reject! I would like to test an updated
> version if you have one (the update seems to refer to better logging
> only, right?).
Hannes,
Any chance you've had time to fold your proposed logging changes in and
rebase this patch? Could you post that updated patch?
I'd like to help see this patch through to inclussion when 2.6.38 merge
window opens. I can help with further review, testing and development.
Please advise, thanks.
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists