All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Ruijter <mruijter@gmail.com>
To: kernel-janitors@vger.kernel.org
Subject: Preparing btier for kernel inclusion
Date: Tue, 12 Feb 2013 08:22:33 +0000	[thread overview]
Message-ID: <5119FBC9.7030308@gmail.com> (raw)


Hi all,

Btier is a kernel based block device that supports automatic policy 
based data migration.
It allows you to assemble a virtual block device from other block 
devices of even files.

For example you can assemble a btier block device that consists of : 
/dev/ssd:/dev/LSIsasArray:/mnt/myNetApp/nfs-disk03.img
Since btier uses the ssd as part of the whole device and not merely as 
cache the capacity of the SSD is a part of the total capacity.
Btier will differentiate between random and sequential IO. And will 
therefore redirect random IO to the most suitable device.
Which in this case would be the SSD.

Another trick that btier uses to speed up random IO is to write it 
sequentially.

Btier performance compared to SSD cache projects (tested with fio, 
details on lessfs.com)
grep iops bcache.txt
Jobs: 1 (f=1): [___w] [87.4% done] [0K/142.3M /s] [0 /35.6K iops] [eta 
00m:34s]
   read : io\x12288MB, bw"8324KB/s, iopsW080 , runt= 55110msec
   read : io\x11250MB, bw\x191989KB/s, iopsG997 , runt= 60001msec
   write: ios94.5MB, bw\x126195KB/s, iops1548 , runt= 60002msec
   write: ioy24.2MB, bw\x135237KB/s, iops3809 , runt= 60001msec
root@ctrl01:/opt/fio# grep iops eio.txt
   read : io\x12288MB, bw%4782KB/s, iopsc695 , runt= 49387msec
   read : ioI42.9MB, bw„356KB/s, iops!089 , runt= 60001msec
   write: io\x11134MB, bw\x190018KB/s, iopsG504 , runt= 60001msec
   write: iow80.8MB, bw\x132788KB/s, iops3197 , runt= 60001msec
root@ctrl01:/opt/fio# grep iops btier.txt
   read : io\x12288MB, bwD8333KB/s, iops\x112083 , runt= 28066msec
   read : io$39.6MB, bwA635KB/s, iops\x10408 , runt= 60001msec
   write: io\x12288MB, bwI3041KB/s, iops\x123260 , runt= 25521msec
   write: io‘72.2MB, bw\x156550KB/s, iops9137 , runt= 60001msec

Although performance is always important, btier is _not_ an SSD cache 
project.
Instead it is much more about ILM.

Before considering to submit btier for inclusion it would be nice if the 
code is looked at from a janitors perspective.
You can find the code at : http://sourceforge.net/projects/tier/files/ 
and general information at : http://www.lessfs.com

I look forward to hearing from you.
Thanks in advance for any feedback that you would like to share.

Mark Ruijter
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2013-02-12  8:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12  8:22 Mark Ruijter [this message]
2013-02-12  9:47 ` Preparing btier for kernel inclusion Dan Carpenter
2013-02-12 10:09 ` Mark Ruijter
2013-02-12 10:23 ` walter harms
2013-02-12 11:26 ` Dan Carpenter

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=5119FBC9.7030308@gmail.com \
    --to=mruijter@gmail.com \
    --cc=kernel-janitors@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 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.