From: Waxhead <waxhead@online.no>
To: Timo Witte <timo.witte@googlemail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Hot data Tracking
Date: Thu, 03 May 2012 15:09:25 +0200 [thread overview]
Message-ID: <4FA28385.7040709@online.no> (raw)
In-Reply-To: <20120221232445.GJ1046@twin.jikos.cz>
David Sterba wrote:
> On Sat, Feb 11, 2012 at 05:49:41AM +0100, Timo Witte wrote:
>> What happened to the hot data tracking feature in btrfs? There are a lot
>> of old patches from aug 2010, but it looks like the feature has been
>> completly removed from the current version of btrfs. Is this feature
>> still on the roadmap?
> Removed? AFAIK it hasn't been ever merged, though it's be a nice
> feature. There were suggestions to turn it into a generic API for any
> filesystem to use, but this hasn't happened.
>
> The patches are quite independent and it was easy to refresh them on top
> of current for-linus branch. A test run did not survive a "random"
> xfstest, 013 this time, so I probably mismerged some bits. The patchset
> lives in branch foreign/ibm/hotdatatrack in my git repo.
>
>
> david
>
Someone recently mentioned bcache in another post who seems to cover
this subject fairly well. However would it not make sense if btrfs
actually was able to automatically take advantage of whatever disks is
added to the pool? For example if you have 10 disk of different size and
performance in a raid5/6 like configuration would it not be feasible if
btrfs automagically (option) could manage it's own cache? For example it
could reserve a chunk of free space as cache (based on how much data is
free) and stripe data over all disks (cache). When the filesystem
becomes idle or at set intervals it could empty the cache or
move/rebalance pending writes over to the original raid5/6 like setup.
As far as I remember hot data tracking was all about moving the data
over to the fastest disk. Why not utilize all disks and benefit from
disks working together?
Svein Engelsgjerd
next prev parent reply other threads:[~2012-05-03 13:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-11 4:49 Hot data Tracking Timo Witte
2012-02-21 23:24 ` David Sterba
2012-05-03 13:09 ` Waxhead [this message]
2012-05-03 21:58 ` Hubert Kario
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=4FA28385.7040709@online.no \
--to=waxhead@online.no \
--cc=linux-btrfs@vger.kernel.org \
--cc=timo.witte@googlemail.com \
/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).