public inbox for linux-raid@vger.kernel.org
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: User space RAID
Date: Wed, 18 Nov 2009 00:14:54 +0100	[thread overview]
Message-ID: <874oosn3pt.fsf@frosties.localdomain> (raw)
In-Reply-To: <20091117193650.GA2748@lazy.lzy> (Piergiorgio Sartor's message of "Tue, 17 Nov 2009 20:37:23 +0100")

Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> writes:

> Hi all,
>
> question for the experts.
>
> It would be possible, excluding performances, to
> build an user-space RAID system?
>
> I mean, something like fuse does, with a user space
> daemon to perform the math, especially for RAID-6,
> and the rest, together with a small kernel module.
>
> Or there are technical limitations which make this
> approach impossible with the current architecture?
>
> Just curious,
>
> bye,

You can use fuse to create a filesystem containing just one file,
which represents your user-raid, and mount that loopback. Since you
can already do it it can't be impossible. It just isn't optimal.


If you are truely interested then look at fuse and cuse and create a
buse along the same lines. I have a few features I would like to see:

1) zero-copy (with splice()?)
   Currently fuse calls read() to get the data for a write
   request. This copies the data into the supplied buffer.
   It would be better if one could splice() the data into a pipe and
   then splice it back onto the actual device/file the data resides
   on.

2) async crypto api support
   Some hardware has support for XOR or AES. The kernel has a nice API
   for this supporting both software and hardware drivers. It would be
   nice if one could interface with that API from userspace. For good
   performance this should be zero-copy again. So one would just
   splice the data into it and splice the result out of it.

3) barrier support
   Currently (last I checked) the loopback device has no barrier
   support and I'm not sure how fuse should act on barriers.
   A buse [Block device in User SpacE] (like fuse and cuse) should
   have a callback for barriers and probably not use the loopback hack.


4) block ioctl support
   Fuse has a callback for ioctls. Not sure if that is sufficient to
   handle block ioctls or if something needs to be added there. But it
   would be nice if one could request the size and geometry and so on.

MfG
        Goswin

      reply	other threads:[~2009-11-17 23:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-17 19:37 User space RAID Piergiorgio Sartor
2009-11-17 23:14 ` Goswin von Brederlow [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=874oosn3pt.fsf@frosties.localdomain \
    --to=goswin-v-b@web.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=piergiorgio.sartor@nexgo.de \
    /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