linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <Anand.Jain@oracle.com>
To: Alin Dobre <alin.dobre@elastichosts.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Monitoring for disk failures
Date: Tue, 28 Jan 2014 17:03:46 +0800	[thread overview]
Message-ID: <52E77272.9090003@oracle.com> (raw)
In-Reply-To: <52E64665.5020109@elastichosts.com>


Alin,

[bug] its messy when missing device reappears after its been replaced in 
RAID1

  I am aware of it and working on it. I also reported a more
  critical bug earlier as below.

  [bug] its messy when missing device reappears after its been replaced 
in RAID1


  We see IO errors when disk goes missing. But NO as of now
  a mounted FS will never report a missing disk unless you
  unmount and mount (not remount) then kernel will realize
  the missing disk

  Note that don;t be happy about
     btrfs fi show -d <all-devices>
  reporting missing disk (when fs is mounted), since its
  not inline with kernel. Here with -d option btrfs-progs
  is adding its 'own' intelligence to show disk as missing
  (what is not what end user want, end user would want to
  know how btrfs kernel is managing the missing disk and
  they want to do it by using btrfs-progs. At many places
  btrfs-progs is way to intelligent than what actually
  needed. That's wrong).

  More to come.

Thanks, Anand



On 01/27/2014 07:43 PM, Alin Dobre wrote:
> Hi all!
>
> I am trying to create a very simple script that would alert in case of
> disk failures from a RAID Btrfs.
>
> Digging into the code, I have noticed that the "btrfs fi sh" command
> should display a warning if there is a missing disk. However, testing in
> a Qemu, I used "drive_del" via QMP to remove a "live" SCSI drive,
> already mounted as part of a RAID10 array, the "fi sh" command still
> gave no indication that the drive is missing. Then, I tried removing a
> scsi disk from the host via "echo 1 >/sys/block/sdX/device/delete" to
> actually make the kernel SCSI host forget about it, and "fi sh" still
> doesn't show anything.
>
> I have tested using btrfs-progs v3.12 and kernel 3.13.0.
>
> Do you guys know what's wrong with the setup explained above or do you
> have any indication on how to detect if there is a failing disk, part of
> a Btrfs RAID?
>
> Cheers,
> Alin.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

      parent reply	other threads:[~2014-01-28  8:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-27 11:43 Monitoring for disk failures Alin Dobre
2014-01-27 13:10 ` Duncan
2014-01-28  9:15   ` Anand Jain
2014-01-28  9:03 ` Anand Jain [this message]

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=52E77272.9090003@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=alin.dobre@elastichosts.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).