All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: waxhead@dirtcellar.net, Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: BTRFS subvolume RAID level
Date: Tue, 3 Dec 2019 09:30:31 +0800	[thread overview]
Message-ID: <422a04ba-2e63-f951-7097-19ecc7a88c53@oracle.com> (raw)
In-Reply-To: <fcbe2d91-a6ad-5b9b-fa66-aebb2edd14f1@dirtcellar.net>



On 12/3/19 7:27 AM, waxhead wrote:
> 
> 
> Anand Jain wrote:
>>
>>> I imagine that RAIDc4 for example could potentially give a grotesque 
>>> speed increase for parallel read operations once BTRFS learns to 
>>> distribute reads to the device with the least waitqueue / fastest 
>>> devices.
>>
>>   That exactly was the objective of the Readmirror patch in the ML.
>>   It proposed a framework to change the readmirror policy as needed.
>>
>> Thanks, Anand
> 
> Indeed. If I remember correctly your patch allowed for deterministic 
> reading from certain devices.
  It provides a framework to configure the readmirror policies. And the
  policies can be based on io-depth, pid, or manual for heterogeneous
  devices with different latency.

> As just a regular btrfs user the problem I 
> see with this is that you loose a "potential free scrub" that *might* 
> otherwise happen from often read data. On the other hand that is what 
> manual scrubbing is for anyway.

  Ha ha.

  When it comes to data and its reliability and availability we need
  guarantee and only deterministic approach can provide it.

  What you are asking for is to route the particular block to
  the device which was not read before so to avoid scrubbing or to
  make scrubbing more intelligent to scrub only old never read blocks
  - this will be challenging we need to keep history of block and the
  device it used for read - most likely a scope for the bpf based
  external tools but definitely not with in kernel. With in kernel
  we can create readmirror like framework so that external tool can
  achieve it.


Thanks, Anand

  reply	other threads:[~2019-12-03  1:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-28 22:48 BTRFS subvolume RAID level waxhead
2019-11-29  0:44 ` Qu Wenruo
2019-12-02 10:48 ` Anand Jain
2019-12-02 23:27   ` waxhead
2019-12-03  1:30     ` Anand Jain [this message]
2019-12-03 20:31       ` waxhead
2019-12-05 12:10         ` 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=422a04ba-2e63-f951-7097-19ecc7a88c53@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=waxhead@dirtcellar.net \
    /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.