linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Charles Manning <manningc2@actrix.gen.nz>
To: Nikolai Joukov <kolya@cs.sunysb.edu>
Cc: Al Boldi <a1426z@gawab.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-raid@vger.kernel.org
Subject: Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems
Date: Fri, 15 Dec 2006 10:30:31 +1300	[thread overview]
Message-ID: <200612151030.31846.manningc2@actrix.gen.nz> (raw)
In-Reply-To: <Pine.GSO.4.53.0612141538410.6095@compserv1>

On Friday 15 December 2006 10:01, Nikolai Joukov wrote:
> > Nikolai Joukov wrote:
> > > We have designed a new stackable file system that we called RAIF:
> > > Redundant Array of Independent Filesystems.
> >
> > Great!

Yes, definitely...

I see the major benefit being in the mobile, industrial and embedded systems 
arena. Perhaps this might come as a suprise to people, but a very large and 
ever growing number (perhaps even most) Linux devices don't use block devices 
for storage. Instead they use flash file systems or nfs, niether of which use 
local block devices.

It looks like RAIF gives a way to provide redundancy etc on these devices.


> >
> > > We have performed some benchmarking on a 3GHz PC with 2GB of RAM and
> > > U320 SCSI disks.  Compared to the Linux RAID driver, RAIF has overheads
> > > of about 20-25% under the Postmark v1.5 benchmark in case of striping
> > > and replication.  In case of RAID4 and RAID5-like configurations, RAIF
> > > performed about two times *better* than software RAID and even better
> > > than an Adaptec 2120S RAID5 controller.
> >
> > I am not surprised.  RAID 4/5/6 performance is highly sensitive to the
> > underlying hw, and thus needs a fair amount of fine tuning.
>
> Nevertheless, performance is not the biggest advantage of RAIF.  For
> read-biased workloads RAID is always slightly faster than RAIF.  The
> biggest advantages of RAIF are flexible configurations (e.g., can combine
> NFS and local file systems), per-file-type storage policies, and the fact
> that files are stored as files on the lower file systems (which is
> convenient).
>
> > > This is because RAIF is located above
> > > file system caches and can cache parity as normal data when needed.  We
> > > have more performance details in a technical report, if anyone is
> > > interested.
> >
> > Definitely interested.  Can you give a link?
>
> The main focus of the paper is on a general OS profiling method and not
> on RAIF.  However, it has some details about the RAIF benchmarking with
> Postmark in Chapter 9:
>
>   <http://www.fsl.cs.sunysb.edu/docs/joukov-phdthesis/thesis.pdf>
>
> Figures 9.7 and 9.8 also show profiles of the Linux RAID5 and RAIF5
> operation under the same Postmark workload.
>
> Nikolai.
> ---------------------
> Nikolai Joukov, Ph.D.
> Filesystems and Storage Laboratory
> Stony Brook University
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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:[~2006-12-14 21:35 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-13 17:47 [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems Nikolai Joukov
2006-12-13 19:02 ` Phillip Susi
2006-12-13 19:17   ` Nikolai Joukov
2006-12-13 19:32     ` Nikolai Joukov
2006-12-13 19:33 ` Jan Engelhardt
2006-12-13 19:57   ` Nikolai Joukov
2006-12-13 19:57 ` Al Boldi
2006-12-14 21:01   ` Nikolai Joukov
2006-12-14 21:30     ` Charles Manning [this message]
2006-12-15 16:48       ` Nikolai Joukov
2006-12-14 22:48     ` berk walker
2006-12-15  5:02     ` Al Boldi
2006-12-15 17:41       ` Nikolai Joukov
     [not found]         ` <200612161635.49502.a1426z@gawab.com>
2006-12-16 17:39           ` Nikolai Joukov
2006-12-19 17:50             ` stacked filesystem cache waste Bryan Henderson
     [not found]             ` <200612172059.07941.a1426z@gawab.com>
2006-12-23  3:21               ` [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems Nikolai Joukov
2006-12-14 11:12 ` Al Boldi
2006-12-14 23:44   ` Nikolai Joukov
2006-12-15  5:03     ` Al Boldi
2006-12-15 18:47       ` Nikolai Joukov
2006-12-15 12:47 ` Ed Tomlinson
2006-12-15 20:11   ` Nikolai Joukov
2006-12-15 23:58     ` Ed Tomlinson
2006-12-16  0:20       ` Bryan Henderson
2006-12-16  1:20         ` Nikolai Joukov
2006-12-16 14:46         ` Ed Tomlinson
2006-12-16 17:57           ` Nikolai Joukov
2006-12-16  0:02 ` David Lang
2006-12-16  0:58   ` Nikolai Joukov
  -- strict thread matches above, loose matches on Subject: below --
2006-12-15  1:13 Nikolai Joukov
     [not found] <OF582D7197.D6F604B1-ON88257248.0069CC60-88257248.006AE165@us.ibm.com>
2006-12-25 15:13 ` Nikolai Joukov
2007-01-06  5:17 Chaitanya Patti

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=200612151030.31846.manningc2@actrix.gen.nz \
    --to=manningc2@actrix.gen.nz \
    --cc=a1426z@gawab.com \
    --cc=kolya@cs.sunysb.edu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@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 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).