On 11/30/2010 11:59 PM, Mike Snitzer wrote: > On Thu, Nov 18 2010 at 10:11pm -0500, > Malahal Naineni <malahal@xxxxxxxxxx> wrote: > >> Hannes Reinecke [hare@xxxxxxx] 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? > yes, will be following shortly. > 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. > Ok, thanks. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
