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.
next prev 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).