Date:	Tue, 23 Feb 2010 08:32:32 -0500
From:	Greg Freemyer <greg.freemyer@...il.com>
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:	Manish Katiyar <mkatiyar@...il.com>,
	OHSM-DEV <ohsm-devel@...ts.sourceforge.net>,
	kernelnewbies <kernelnewbies@...linux.org>,
	ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [ANNOUNCE] Online Hierarchical Storage Manager (OHSM v1.2)

On Tue, Feb 23, 2010 at 2:14 AM, Dmitry Monakhov <dmonakhov@...nvz.org> wrote:
> Manish Katiyar <mkatiyar@...il.com> writes:
>
>> Hello all,
>>    We are pleased to announce the first official functional release of Online
>> Hierarchical Storage Manager (OHSM v1.2).  This is a RFC release and
>> not yet aimed at mainline inclusion.
>>
>> OHSM is a tool to manage and move data across various class of storage.
>> It can help users to selectively place and move data across tiers such
>> as SSD, Raid 10, Raid 6 based on the attributes of the data. OHSM
>> supports background movement of data
>> without any visible change in a files namespace to users and user applications.
> It does sounds like btrfs multy-device support. Can you please
> what it the differance?

Dmitry,

Per my understanding of btrfs multi-device, ohsm is totally different.

Btrfs multi-device I believe provides functionality similar to DM
(device mapper) and/or mdraid.

Ohsm is about cost effectively managing multiple storage tiers within
a single filesystem and leverages having DM and mdraid available to
build on, but makes no effort to duplicate their functionality.  DM in
particular is a mandatory part of a ohsm environment.

For example:

Assume I have an enterprise app that needs 10 TB of storage, but 90%
of the data is of limited use most of the time.  The other 10% is
heavily used and high performance is paramount.  The trouble is that
from time-to-time the designation of the 10% changes as business needs
change.  ie. Normally I really need database abc to be fast, but at
the end of the month I need database xyz to be as fast as possible.

One real world solution without OHSM is to create a SSD raid-1 that
holds the 10%, (1TB), and a SATA raid 6 that holds the less critical
90% (9TB).

Then, as just one example, if I need to accelerate a database for a
few days / weeks I simply move the database tables from the
low-performance file system to the high-performance file system.  And
I see my database speed drastically accelerate.

There are 2 big downsides to the above:

1) The full path name to the database tables will change as they are
moved between file systems, so it is a admin hassle to update
references to the tables as they move around.

2) The tables can not be in use as they are moved, so if I really am
moving a TB of data between sata and SSD that could take some number
of hours where I can't be actively using the files.  A definite
downtime issue.

Now with OHSM, we would build a DM logical volume composed of a sata
raid array and a ssd raid array.  Thus blocks 0-x would be on the sata
array and blocks x-end would be on SSD.

We would then use ohsm to manage which block range was used by the
various files.  The goal being that low-performance files would be
stored on sata devices and files needing high-performance would be
stored on SSD.

And as the performance needs of the files changed, the files could be
moved between the tiers.  The files blocks are moved via
ext4_ioc_move_ext() so the path'ing is not changed and the file can be
open and in use as it is moved.

In a sense we are performing a defrag action on the file where the
destination blocks of the file are in a different storage tier than
the original data blocks.

fyi: One of the ways we track desired storage tier for a file is via
subtrees, thus the interest of ohsm in your subtree implementation.

HTH
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists