Re: [RFC PATCH 0/5] Btrfs: Add hot data tracking functionality

From: Christian Stroetmann
Date: Thu Jul 29 2010 - 09:13:48 EST


Aloha Mingming, Aloha Dave;

On the 29.07.2010 14:17, Dave Chinner wrote:
On Wed, Jul 28, 2010 at 03:00:48PM -0700, Mingming Cao wrote:
On Wed, 2010-07-28 at 01:38 +0200, Christian Stroetmann wrote:
At the 28.07.2010 00:00, Ben Chociej wrote:
Wouldn't this feature be useful for other file systems as well, so that
a more general and not an only Btrfs related solution is preferable?

Would certainly nice to add this feature to all filesystem, but right
now btrfs is the only fs which have multiple device support in itself.

Thanks for your explanation, Mingming. And I had further questions to this point, but didn't know exactly how to formulate them in a short way. But luckily Dave has a possible solution that is related with my questions around the multiple device feature of Btrfs and hot data handling.

Why does it even need multiple devices in the filesystem?

Yes, that was the point I asked myself after reading about this in the Btrfs wiki (https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices) and how ZFS does it.

All the
filesystem needs to know is the relative speed of regions of it's
block address space and to be provided allocation hints. everything
else is just movement of data. You could keep the speed information
in the device mapper table and add an interface for filesystems to
query it, and then you've got infrastructure that all filesystems
could hook into.

Yes indeed, something like this general solution that doesn't need the multiple device feature at all.

The tracking features dont' appear to have anything btrfs specific
in them, so t iseems wrong to implement it there just because you're
only looking at btrfs' method of tracking multiple block devices
and moving blocks....

Cheers,

Dave.

Thank you very much for being creative. :D

Cheerio
Christian *<:o) O>-< -(D)>-<

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/