From: Shaohua Li <shaohua.li@intel.com>
To: Hubert Kario <hka@qbs.com.pl>
Cc: "bchociej@gmail.com" <bchociej@gmail.com>,
"chris.mason@oracle.com" <chris.mason@oracle.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"cmm@us.ibm.com" <cmm@us.ibm.com>,
"bcchocie@us.ibm.com" <bcchocie@us.ibm.com>,
"mrlupfer@us.ibm.com" <mrlupfer@us.ibm.com>,
"crscott@us.ibm.com" <crscott@us.ibm.com>,
"mlupfer@gmail.com" <mlupfer@gmail.com>,
"conscott@vt.edu" <conscott@vt.edu>
Subject: Re: [RFC v2 PATCH 0/6] Btrfs: Add hot data relocation functionality
Date: Mon, 30 Aug 2010 09:05:29 +0800 [thread overview]
Message-ID: <1283130329.16633.2.camel@sli10-conroe.sh.intel.com> (raw)
In-Reply-To: <201008300242.27331.hka@qbs.com.pl>
On Mon, 2010-08-30 at 08:42 +0800, Hubert Kario wrote:
> On Thursday 26 of August 2010 04:13:43 Shaohua Li wrote:
> > On Fri, Aug 13, 2010 at 06:22:00AM +0800, bchociej@gmail.com wrote:
> > > - Hooks in existing Btrfs functions to track data access frequency
> > >
> > > (btrfs_direct_IO, btrfs_readpages, and extent_write_cache_pages)
> > >
> > > - New rbtrees for tracking access frequency of inodes and sub-file
> > >
> > > ranges (hotdata_map.c)
> > >
> > > - A hash list for indexing data by its temperature (hotdata_hash.c)
> > >
> > > - A debugfs interface for dumping data from the rbtrees (debugfs.c)
> > >
> > > - A background kthread for relocating data to faster media based on
> > >
> > > temperature
> >
> > Hi,
> > I'm wondering if the temperature info can be exported to userspace, and
> > let a daemon to do the relocation (by ioctl). A userspace daemon is more
> > flexible.
>
> Flexibility of userspace daemon is one thing, the ability to let the admin
> precisely control on which drive data is placed could be really beneficial in
> some scenarios is another thing.
>
> This would also allow online defragmentation, together with access to
> statistics, one that (for quick runs) has really good time/performance benefit
> ratio.
Agreed, I'm thinking of the online defragmentation based on hot access
too. Btrfs usually has more fragment.
prev parent reply other threads:[~2010-08-30 1:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-12 22:22 [RFC v2 PATCH 0/6] Btrfs: Add hot data relocation functionality bchociej
2010-08-12 22:22 ` [RFC v2 PATCH 1/6] Btrfs: Add experimental hot data hash list index bchociej
2010-08-12 22:22 ` [RFC v2 PATCH 2/6] Btrfs: Add data structures for hot data tracking bchociej
2010-08-12 22:22 ` [RFC v2 PATCH 3/6] Btrfs: Add hot data relocation facilities bchociej
2010-08-12 22:22 ` [RFC v2 PATCH 4/6] Btrfs: Add debugfs interface for hot data stats bchociej
2010-08-12 22:22 ` [RFC v2 PATCH 5/6] Btrfs: 3 new ioctls related to hot data features bchociej
2010-08-12 22:22 ` [RFC v2 PATCH 6/6] Btrfs: Add hooks to enable hot data tracking bchociej
2010-08-26 2:13 ` [RFC v2 PATCH 0/6] Btrfs: Add hot data relocation functionality Shaohua Li
2010-08-30 0:42 ` Hubert Kario
2010-08-30 0:42 ` Hubert Kario
2010-08-30 0:42 ` Hubert Kario
2010-08-30 1:05 ` Shaohua Li [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=1283130329.16633.2.camel@sli10-conroe.sh.intel.com \
--to=shaohua.li@intel.com \
--cc=bcchocie@us.ibm.com \
--cc=bchociej@gmail.com \
--cc=chris.mason@oracle.com \
--cc=cmm@us.ibm.com \
--cc=conscott@vt.edu \
--cc=crscott@us.ibm.com \
--cc=hka@qbs.com.pl \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlupfer@gmail.com \
--cc=mrlupfer@us.ibm.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 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.