From: Alan Stern <stern@rowland.harvard.edu> To: Jan Kara <jack@suse.cz> Cc: tmhikaru@gmail.com, Boaz Harrosh <bharrosh@panasas.com>, Kernel development list <linux-kernel@vger.kernel.org>, USB list <linux-usb@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>, SCSI development list <linux-scsi@vger.kernel.org>, <linux-ext4@vger.kernel.org> Subject: Re: Weird I/O errors with USB hard drive not remounting filesystem readonly Date: Wed, 25 Nov 2009 11:10:48 -0500 (EST) [thread overview] Message-ID: <Pine.LNX.4.44L0.0911251052020.2879-100000@iolanthe.rowland.org> (raw) In-Reply-To: <20091125084240.GA549@quack.suse.cz> On Wed, 25 Nov 2009, Jan Kara wrote: > > > > > Okay, very good. There remains the question of the disturbing error > > > > > messages in the system log. Should they be supressed for FAILFAST > > > > > requests? > > > > I think it's useful they are there because ultimately, something really > > > > went wrong and you should better investigate. BTW, "end_request: I/O error" > > > > messages are in the log even for requests where we retried and succeeded... That isn't true. Take a look at the dmesg log accompanying Tim's usbmon log. Although there were 5 read errors in the usbmon log, there were only 2 I/O error messages in dmesg, corresponding to the 2 reads that weren't retried successfully. Personally, I think it makes little sense to print error messages in the system log for commands where retries are disallowed. Unless we go ahead and print error messages for _all_ failures, including those which are retried successfully. Perhaps a good compromise would be to set the REQ_QUIET flag in req->cmd_flags for readaheads. That would suppress the error messages coming from the SCSI core. > Yeah, we might make it more obvious that read failed and whether or not > we are going to retry. Just technically it's not so simple because a > different layer prints messages about errors (generic block layer) and > different (scsi disk driver) decides what to do (retry, don't retry, ...). Actually the retry decisions (or many of them) are made by the SCSI core, and that's also where some of those error messages come from. > > I should have asked since I'm here at the moment - do you need any > > more information out of the buggy USB enclosure at the moment, or can I work > > on trying to fix/replace it now? > No, feel free to do anything with it :). Thanks for your help with > debugging this. To clarify, the enclosure isn't really very buggy. It _should_ have carried out the failed commands, or if it had a valid reason for not doing so then it _should_ have reported the reason. Regardless, the errors that occurred were harmless because they went away when the commands were retried. (Although if they weren't harmless, you wouldn't be able to tell just from reading the system log...) Alan Stern
WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu> To: Jan Kara <jack@suse.cz> Cc: tmhikaru@gmail.com, Boaz Harrosh <bharrosh@panasas.com>, Kernel development list <linux-kernel@vger.kernel.org>, USB list <linux-usb@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>, SCSI development list <linux-scsi@vger.kernel.org>, linux-ext4@vger.kernel.org Subject: Re: Weird I/O errors with USB hard drive not remounting filesystem readonly Date: Wed, 25 Nov 2009 11:10:48 -0500 (EST) [thread overview] Message-ID: <Pine.LNX.4.44L0.0911251052020.2879-100000@iolanthe.rowland.org> (raw) In-Reply-To: <20091125084240.GA549@quack.suse.cz> On Wed, 25 Nov 2009, Jan Kara wrote: > > > > > Okay, very good. There remains the question of the disturbing error > > > > > messages in the system log. Should they be supressed for FAILFAST > > > > > requests? > > > > I think it's useful they are there because ultimately, something really > > > > went wrong and you should better investigate. BTW, "end_request: I/O error" > > > > messages are in the log even for requests where we retried and succeeded... That isn't true. Take a look at the dmesg log accompanying Tim's usbmon log. Although there were 5 read errors in the usbmon log, there were only 2 I/O error messages in dmesg, corresponding to the 2 reads that weren't retried successfully. Personally, I think it makes little sense to print error messages in the system log for commands where retries are disallowed. Unless we go ahead and print error messages for _all_ failures, including those which are retried successfully. Perhaps a good compromise would be to set the REQ_QUIET flag in req->cmd_flags for readaheads. That would suppress the error messages coming from the SCSI core. > Yeah, we might make it more obvious that read failed and whether or not > we are going to retry. Just technically it's not so simple because a > different layer prints messages about errors (generic block layer) and > different (scsi disk driver) decides what to do (retry, don't retry, ...). Actually the retry decisions (or many of them) are made by the SCSI core, and that's also where some of those error messages come from. > > I should have asked since I'm here at the moment - do you need any > > more information out of the buggy USB enclosure at the moment, or can I work > > on trying to fix/replace it now? > No, feel free to do anything with it :). Thanks for your help with > debugging this. To clarify, the enclosure isn't really very buggy. It _should_ have carried out the failed commands, or if it had a valid reason for not doing so then it _should_ have reported the reason. Regardless, the errors that occurred were harmless because they went away when the commands were retried. (Although if they weren't harmless, you wouldn't be able to tell just from reading the system log...) Alan Stern
next prev parent reply other threads:[~2009-11-25 16:10 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-11-13 5:09 Weird I/O errors with USB hard drive not remounting filesystem readonly tmhikaru 2009-11-19 16:07 ` Jan Kara [not found] ` <20091120082359.GA29538@roll> [not found] ` <20091120094641.GB15422@duck.suse.cz> 2009-11-23 8:09 ` tmhikaru 2009-11-23 10:54 ` Jan Kara 2009-11-23 15:06 ` Alan Stern 2009-11-23 15:06 ` Alan Stern 2009-11-23 16:09 ` Jan Kara 2009-11-23 18:20 ` Alan Stern 2009-11-23 18:20 ` Alan Stern 2009-11-23 18:54 ` Jan Kara 2009-11-23 19:50 ` tmhikaru 2009-11-23 20:06 ` tmhikaru 2009-11-23 20:06 ` tmhikaru-Re5JQEeQqe8AvxtiuMwx3w 2009-11-23 20:33 ` Alan Stern 2009-11-23 20:33 ` Alan Stern 2009-11-23 23:42 ` tmhikaru 2009-11-23 23:42 ` tmhikaru-Re5JQEeQqe8AvxtiuMwx3w 2009-11-24 17:16 ` Alan Stern 2009-11-24 17:16 ` Alan Stern 2009-11-24 17:47 ` Boaz Harrosh 2009-11-24 19:28 ` Alan Stern 2009-11-24 19:28 ` Alan Stern 2009-11-24 19:56 ` Jan Kara 2009-11-24 20:13 ` Alan Stern 2009-11-24 20:13 ` Alan Stern 2009-11-24 20:39 ` Jan Kara 2009-11-24 21:50 ` tmhikaru 2009-11-24 22:23 ` tmhikaru 2009-11-25 8:42 ` Jan Kara 2009-11-25 9:37 ` tmhikaru 2009-11-25 16:10 ` Alan Stern [this message] 2009-11-25 16:10 ` Alan Stern 2009-11-27 9:43 ` tmhikaru 2009-11-27 13:13 ` Jan Kara 2009-11-27 17:58 ` Alan Stern 2009-11-27 17:58 ` Alan Stern 2009-11-27 17:58 ` Alan Stern 2009-11-29 4:30 ` tmhikaru 2009-11-24 18:00 ` Jan Kara
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.4.44L0.0911251052020.2879-100000@iolanthe.rowland.org \ --to=stern@rowland.harvard.edu \ --cc=axboe@kernel.dk \ --cc=bharrosh@panasas.com \ --cc=jack@suse.cz \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=tmhikaru@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.