linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Juan Orti Alcaine <j.orti.alcaine@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
	Marco Lorenzo Crociani <marcoc@prismatelecomtesting.com>,
	Roman Mamedov <rm@romanrm.net>
Subject: Re: mount time for big filesystems
Date: Fri, 1 Sep 2017 11:20:27 -0400	[thread overview]
Message-ID: <208a4dda-0628-1e1b-1118-b8921f86fedd@gmail.com> (raw)
In-Reply-To: <CAC+fKQWFbdF6b3jGO_6hG_pNNzKobBYMeSNyEi5XRCf5YKa81Q@mail.gmail.com>

On 2017-09-01 11:00, Juan Orti Alcaine wrote:
> 
> 
> El 1 sept. 2017 15:59, "Austin S. Hemmelgarn" <ahferroin7@gmail.com 
> <mailto:ahferroin7@gmail.com>> escribió:
> 
>     If you are going to use bcache, you don't need separate caches for
>     each device (and in fact, you're probably better off sharing a cache
>     across devices).
> 
> 
> But, if I mix all the backing devices, I'll only get one bcache device, 
> so I won't be able to do btrfs RAID1 on that.
No, that's not what I'm talking about.  You always get one bcache device 
per backing device, but multiple bcache devices can use the same 
physical cache device (that is, backing devices map 1:1 to bcache 
devices, but cache devices can map 1:N to bcache devices).  So, in other 
words, the layout I'm suggesting looks like this:

/dev/sda1: Backing device.
/dev/sdb1: Backing device.
/dev/sdc1: Backing device.
/dev/sdd1: Backing device.
/dev/sde1: SSD cache device.
/dev/bcache0: Corresponds to /dev/sda1, uses /dev/sde1 as cache
/dev/bcache1: Corresponds to /dev/sdb1, uses /dev/sde1 as cache
/dev/bcache2: Corresponds to /dev/sdc1, uses /dev/sde1 as cache
/dev/bcache3: Corresponds to /dev/sdd1, uses /dev/sde1 as cache

This is actually simpler to manage for multiple reasons, and will avoid 
wasting space on the cache device because of random choices made by 
BTRFS when deciding where to read data.

  parent reply	other threads:[~2017-09-01 15:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-31 10:43 mount time for big filesystems Marco Lorenzo Crociani
2017-08-31 11:00 ` Hans van Kranenburg
2017-08-31 11:22   ` Austin S. Hemmelgarn
2017-08-31 11:36 ` Roman Mamedov
2017-08-31 11:45   ` Austin S. Hemmelgarn
2017-08-31 12:16     ` Roman Mamedov
2017-08-31 14:13   ` Qu Wenruo
2017-09-01 13:52   ` Juan Orti Alcaine
2017-09-01 13:59     ` Austin S. Hemmelgarn
     [not found]       ` <CAC+fKQWFbdF6b3jGO_6hG_pNNzKobBYMeSNyEi5XRCf5YKa81Q@mail.gmail.com>
2017-09-01 15:20         ` Austin S. Hemmelgarn [this message]
2017-09-01 22:41           ` Dan Merillat

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=208a4dda-0628-1e1b-1118-b8921f86fedd@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=j.orti.alcaine@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=marcoc@prismatelecomtesting.com \
    --cc=rm@romanrm.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 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).