All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: bo.li.liu@oracle.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v8 2/2] btrfs: check device for critical errors and mark failed
Date: Thu, 5 Oct 2017 21:56:59 +0800	[thread overview]
Message-ID: <881db992-2240-ce30-4d05-d0bd1faa2aa4@oracle.com> (raw)
In-Reply-To: <20171004201154.GB4902@dhcp-10-211-47-181.usdhcp.oraclecorp.com>



On 10/05/2017 04:11 AM, Liu Bo wrote:
> On Tue, Oct 03, 2017 at 11:59:20PM +0800, Anand Jain wrote:
>> From: Anand Jain <Anand.Jain@oracle.com>
>>
>> Write and flush errors are critical errors, upon which the device fd
>> must be closed and marked as failed.
>>
> 
> Can we defer the job of closing device to umount?

  Originally I think it was designed to handle the bad disk
  same as missing device. as below [1]. This patch just does that.
  But I am curious to know if there is any issue to close failed
  device ?

[1]
-----
static int read_one_dev(struct btrfs_fs_info *fs_info,
                         struct extent_buffer *leaf,
                         struct btrfs_dev_item *dev_item)
::
             /*
              * this happens when a device that was properly setup
              * in the device info lists suddenly goes bad.
              * device->bdev is NULL, and so we have to set
              * device->missing to one here
              */
------

  So here I misuse the device missing scenario (device->bdev = NULL)
  to the failed device scenario. (code comment mentioned it).

  Secondly as in the patch 1/2 commit log and also Austin mentioned it,
  if failed device close is deferred it will also defer the cleanup of
  the failed device at the block layer.

  But yes block layer can still clean up when btrfs closes the
  device at the time of replace, also where in the long run, pulling
  out of the failed disk would (planned) trigger a udev notification
  into the btrfs sysfs interface and it can close the device.

  Anything that I have missed ?

  Further, jfyi closing of failed device isn't related to the
  looping for device failure though.

> We can go mark the device failed and skip it while doing read/write,
> and umount can do the cleanup work.

  In servers a need of umount is considered as downtime, things
  shouldn't wait for umount to cleanup.

> That way we don't need a dedicated thread looping around to detect a
> rare situation.

  I think its better to make it event based instead of thread looping,
  pls take a look..

    [PATCH v8.1 2/2] btrfs: mark device failed for write and flush errors

Thanks, Anand


> Thanks,
> 
> -liubo

  parent reply	other threads:[~2017-10-05 13:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03 15:59 [PATCH v8 0/2] [RFC] Introduce device state 'failed' Anand Jain
2017-10-03 15:59 ` [PATCH v8 1/2] btrfs: introduce device dynamic state transition to failed Anand Jain
2017-10-13 18:47   ` Liu Bo
2017-10-16  6:09     ` Anand Jain
2017-10-03 15:59 ` [PATCH v8 2/2] btrfs: check device for critical errors and mark failed Anand Jain
2017-10-04 20:11   ` Liu Bo
2017-10-05 11:07     ` Austin S. Hemmelgarn
2017-10-06 23:33       ` Liu Bo
2017-10-09 11:58         ` Austin S. Hemmelgarn
2017-10-05 13:56     ` Anand Jain [this message]
2017-10-06 23:56       ` Liu Bo
2017-10-08 14:23         ` Anand Jain
2017-10-13 18:46           ` Liu Bo
2017-10-16  6:09             ` Anand Jain
2017-10-05 13:54 ` [PATCH v8.1 2/2] btrfs: mark device failed for write and flush errors Anand Jain

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=881db992-2240-ce30-4d05-d0bd1faa2aa4@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=bo.li.liu@oracle.com \
    --cc=linux-btrfs@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.