From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Ferry Toth <ftoth@exalondelft.nl>, linux-btrfs@vger.kernel.org
Subject: Re: Hot data tracking / hybrid storage
Date: Mon, 16 May 2016 07:25:09 -0400 [thread overview]
Message-ID: <796f1fb5-8e96-39e1-7149-eb67b9d4847f@gmail.com> (raw)
In-Reply-To: <nh9p2p$cns$1@ger.gmane.org>
On 2016-05-15 08:12, Ferry Toth wrote:
> Is there anything going on in this area?
>
> We have btrfs in RAID10 using 4 HDD's for many years now with a rotating
> scheme of snapshots for easy backup. <10% files (bytes) change between
> oldest snapshot and the current state.
>
> However, the filesystem seems to become very slow, probably due to the
> RAID10 and the snapshots.
While it's not exactly what you're thinking of, have you tried running
BTRFS in raid1 mode on top of two DM/MD RAID0 volumes? This provides
the same degree of data integrity that BTRFS raid10 does, but gets
measurably better performance.
>
> It would be fantastic if we could just add 4 SSD's to the pool and btrfs
> would just magically prefer to put often accessed files there and move
> older or less popular files to the HDD's.
>
> In my simple mind this can not be done easily using bcache as that would
> require completely rebuilding the file system on top of bcache (can not
> just add a few SSD's to the pool), while implementing a cache inside btrfs
> is probably a complex thing with lots of overhead.
You may want to look into dm-cache, as that doesn't require reformatting
the source device. It doesn't quite get the same performance as bcache,
but for me at least, the lower performance is a reasonable trade-off for
being able to easily convert a device to use it, and being able to
easily convert away from it if need be.
>
> Simply telling the allocator to prefer new files to go to the ssd and
> move away unpopular stuff to hdd during balance should do the trick, or am
> I wrong?
In theory this would work as a first implementation, but it would need
to have automatic data migration as an option to be considered
practical, and that's not as easy to do correctly.
prev parent reply other threads:[~2016-05-16 11:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-15 12:12 Hot data tracking / hybrid storage Ferry Toth
2016-05-15 21:11 ` Duncan
2016-05-15 23:05 ` Kai Krakow
2016-05-17 6:27 ` Ferry Toth
2016-05-17 11:32 ` Austin S. Hemmelgarn
2016-05-17 18:33 ` Kai Krakow
2016-05-18 22:44 ` Ferry Toth
2016-05-19 18:09 ` Kai Krakow
2016-05-19 18:51 ` Austin S. Hemmelgarn
2016-05-19 21:01 ` Kai Krakow
2016-05-20 11:46 ` Austin S. Hemmelgarn
2016-05-19 23:23 ` Henk Slager
2016-05-20 12:03 ` Austin S. Hemmelgarn
2016-05-20 17:02 ` Ferry Toth
2016-05-20 17:59 ` Austin S. Hemmelgarn
2016-05-20 21:31 ` Henk Slager
2016-05-29 6:23 ` Andrei Borzenkov
2016-05-29 17:53 ` Chris Murphy
2016-05-29 18:03 ` Holger Hoffstätte
2016-05-29 18:33 ` Chris Murphy
2016-05-29 20:45 ` Ferry Toth
2016-05-31 12:21 ` Austin S. Hemmelgarn
2016-06-01 10:45 ` Dmitry Katsubo
2016-05-20 22:26 ` Henk Slager
2016-05-23 11:32 ` Austin S. Hemmelgarn
2016-05-16 11:25 ` Austin S. Hemmelgarn [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=796f1fb5-8e96-39e1-7149-eb67b9d4847f@gmail.com \
--to=ahferroin7@gmail.com \
--cc=ftoth@exalondelft.nl \
--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).