[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] training mpath to discern between SCSI errors
- From: Mike Snitzer <snitzer redhat com>
- To: Hannes Reinecke <hare suse de>
- Cc: Kiyoshi Ueda <k-ueda ct jp nec com>, michaelc cs wisc edu, tytso mit edu, Sergei Shtylyov <sshtylyov mvista com>, linux-scsi vger kernel org, jaxboe fusionio com, jack suse cz, linux-fsdevel vger kernel org, linux-kernel vger kernel org, swhiteho redhat com, linux-raid vger kernel org, linux-ide vger kernel org, device-mapper development <dm-devel redhat com>, James Bottomley suse de, konishi ryusuke lab ntt co jp, Jun'ichi Nomura <j-nomura ce jp nec com>, vst vlnb net, rwheeler redhat com, Christoph Hellwig <hch lst de>, chris mason oracle com, Tejun Heo <tj kernel org>
- Subject: Re: [dm-devel] training mpath to discern between SCSI errors
- Date: Tue, 30 Nov 2010 17:59:56 -0500
On Thu, Nov 18 2010 at 10:11pm -0500,
Malahal Naineni <malahal us ibm com> wrote:
> Hannes Reinecke [hare suse 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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]