All of lore.kernel.org
 help / color / mirror / Atom feed
From: TomK <tk@mdevsys.com>
To: Wols Lists <antlists@youngman.org.uk>, linux-raid@vger.kernel.org
Subject: Re: [ LR] Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.
Date: Mon, 31 Oct 2016 22:40:58 -0400	[thread overview]
Message-ID: <bf8964fa-9279-6c69-9425-9e1bea89abbf@mdevsys.com> (raw)
In-Reply-To: <58179B9F.8090809@youngman.org.uk>

On 10/31/2016 3:29 PM, Wols Lists wrote:
> On 30/10/16 18:56, TomK wrote:
>>
>> We did not do a thorough R/W test to see how the error and bad disk
>> affected the data stored on the array but did notice pauses and
>> slowdowns on the CIFS share presented from it with pauses and generally
>> difficulty in reading data, however no data errors that we could see.
>> Since then we replaced the 2TB Seagate with a new 2TB WD and everything
>> is fine even if the array is degraded.  But as soon as we put in this
>> bad disk, it degraded to it's previous behaviour.  Yet the array didn't
>> catch it as a failed disk until the disk was nearly completely
>> inaccessible.
>
> What is this 2TB Seagate? A Barracuda? There's your problem, quite
> possibly. Sounds like you've got your timeouts correctly matched, so
> this drive is responding, but taking ages to do so. And that's why it
> doesn't get kicked, but it knackers system response times - the kernel
> is correctly configured to wait for the geriatric to respond.
>
> Cheers,
> Wol
>

Hey Wols,

It's about a 2-3 year old Seagate but not a Barracuda.  They did not 
come with high ratings back then.  I also do adjust other recommended 
settings like write caches etc.

With the previous answer provided by Andreas, I got a very good picture 
what scope of issues RAID should cover and what is not.

So rightly so there is a gap where RAID will not cover all disk failures 
while the disk may impact the applications sitting on top of the array.

Where I was going with this as well is to help me identify what other 
tools I may need in solutions that use RAID.  In this case the answer 
Andreas provided tells me I have to have specific software for disk 
monitoring to the array that would tell me potential issues ahead of 
time alongside the RAID.

On a side note, I like to see the RAID mailing lists so busy.  If I were 
to read the various blog posts, I would believe RAID died 5 years ago.  :)

-- 
Cheers,
Tom K.
-------------------------------------------------------------------------------------

Living on earth is expensive, but it includes a free trip around the sun.


  reply	other threads:[~2016-11-01  2:40 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-30  2:16 Buffer I/O error on dev md5, logical block 7073536, async page read Marc MERLIN
2016-10-30  9:33 ` Andreas Klauer
2016-10-30 15:38   ` Marc MERLIN
2016-10-30 16:19     ` Andreas Klauer
2016-10-30 16:34       ` Phil Turmel
2016-10-30 17:12         ` clearing blocks wrongfully marked as bad if --update=no-bbl can't be used? Marc MERLIN
2016-10-30 17:16           ` Marc MERLIN
2016-11-04 18:18             ` Marc MERLIN
2016-11-04 18:22               ` Phil Turmel
2016-11-04 18:50                 ` Marc MERLIN
2016-11-04 18:59                   ` Roman Mamedov
2016-11-04 19:31                     ` Roman Mamedov
2016-11-04 20:02                       ` Marc MERLIN
2016-11-04 19:51                     ` Marc MERLIN
2016-11-07  0:16                       ` NeilBrown
2016-11-07  1:13                         ` Marc MERLIN
2016-11-07  3:36                           ` Phil Turmel
2016-11-07  1:20                         ` Marc MERLIN
2016-11-07  1:39                           ` Qu Wenruo
2016-11-07  4:18                             ` Qu Wenruo
2016-11-07  5:36                               ` btrfs support for filesystems >8TB on 32bit architectures Marc MERLIN
2016-11-07  6:16                                 ` Qu Wenruo
2016-11-07 14:55                                   ` Marc MERLIN
2016-11-08  0:35                                     ` Qu Wenruo
2016-11-08  0:39                                       ` Marc MERLIN
2016-11-08  0:43                                         ` Qu Wenruo
2016-11-08  1:06                                           ` Marc MERLIN
2016-11-08  1:17                                             ` Qu Wenruo
2016-11-08 15:24                                               ` Marc MERLIN
2016-11-09  1:50                                                 ` Qu Wenruo
2016-11-09  2:05                                                   ` Marc MERLIN
2016-11-11  3:48                                                     ` Marc MERLIN
2016-11-11  3:55                                                       ` Qu Wenruo
2016-11-12  3:17                                                         ` when btrfs scrub reports errors and btrfs check --repair does not Marc MERLIN
2016-11-13 15:06                                                           ` Marc MERLIN
2016-11-13 15:13                                                             ` Roman Mamedov
2016-11-13 15:52                                                               ` Marc MERLIN
2016-10-30 18:56         ` [ LR] Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds TomK
2016-10-30 19:16           ` TomK
2016-10-30 20:13           ` Andreas Klauer
2016-10-30 21:08             ` TomK
2016-10-31 19:29           ` Wols Lists
2016-11-01  2:40             ` TomK [this message]
2016-10-30 16:43       ` Buffer I/O error on dev md5, logical block 7073536, async page read Marc MERLIN
2016-10-30 17:02         ` Andreas Klauer
2016-10-31 19:24         ` Wols Lists
  -- strict thread matches above, loose matches on Subject: below --
2016-10-30 18:34 btrfs check --repair: ERROR: cannot read chunk root Marc MERLIN
2016-10-31  1:02 ` Qu Wenruo
2016-10-31  2:06   ` Marc MERLIN
2016-10-31  4:21     ` Marc MERLIN
2016-10-31  5:27     ` Qu Wenruo
2016-10-31  5:47       ` Marc MERLIN
2016-10-31  6:04         ` Qu Wenruo
2016-10-31  6:25           ` Marc MERLIN
2016-10-31  6:32             ` Qu Wenruo
2016-10-31  6:37               ` Marc MERLIN
2016-10-31  7:04                 ` Qu Wenruo
2016-10-31  8:44                   ` Hugo Mills
2016-10-31 15:04                     ` Marc MERLIN
2016-11-01  3:48                       ` Marc MERLIN
2016-11-01  4:13                       ` Qu Wenruo
2016-11-01  4:21                         ` Marc MERLIN
2016-11-04  8:01                           ` Marc MERLIN
2016-11-04  9:00                             ` Roman Mamedov
2016-11-04 17:59                               ` Marc MERLIN
2016-11-07  1:11                             ` Qu Wenruo

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=bf8964fa-9279-6c69-9425-9e1bea89abbf@mdevsys.com \
    --to=tk@mdevsys.com \
    --cc=antlists@youngman.org.uk \
    --cc=linux-raid@vger.kernel.org \
    /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: link
Be 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.