From: Graeme Sheppard <nodes@rillion.net>
To: linux-kernel@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: Patent or not patent a new idea
Date: Tue, 26 Jun 2007 13:32:59 +1200 [thread overview]
Message-ID: <46806CCB.6020708@rillion.net> (raw)
In-Reply-To: <46803772.7020408@rillion.net>
Posting it here seems the best thing to do.
To the inventor goes naming privilege and I'm calling this one softer raid.
It is a form of storage raid implemented in software, as contrasted to
software and hardware raid which are dependent on using required hardware.
To create a loop filesystem is straight forward. The commands are dd,
mkfs.*, mount -o loop. Basically what I propose is that the image file is
copied to another harddisk (in the case of ide not on the same cable) and
it too is mounted in conjunction of the original with cooperation. When a
read request for a block of say 100k is made, the kernel pulls 50k from
each disk - maybe a simple doubling of throughput.
That example is a raid 1 scenario. Other raid levels I don't think would be
so simple to achieve. Of course more than 2 disks could be harnessed.
The two big advantages I see over normal raid setups are 1) the disks need
not be the same size or from the same manufacturer; 2) the supporting code
would be cross-platform.
It allows users to more freely create and change partitions (which hold
softer raid images) and their sizes.
The downside is that softer raid would be slower than traditional raid
techniques on the right hardware, as softer raid goes through another
filesystem. Softer raid could be optimized for contiguous image files
perhaps.
Using softer raid could also provide sufficient throughput of flash devices
making for a great combo with low latency.
I am not versed enough to suggest how a kernel would implement the storage
access, in 512 or 4096 byte blocks or in what way the reassembling of
pieces would be done efficiently. Therefore I'm not completely sure of any
performance gains.
Is this a good idea or have I overlooked a catch and got lost?
next prev parent reply other threads:[~2007-06-26 1:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-25 21:45 Patent or not patent a new idea Graeme Sheppard
2007-06-25 22:04 ` alan
2007-06-25 22:26 ` Graeme Sheppard
2007-06-25 22:33 ` alan
2007-06-25 22:34 ` Attila Kinali
2007-06-25 22:37 ` manningc2
2007-06-26 0:11 ` Bryan Henderson
2007-06-26 1:32 ` Graeme Sheppard [this message]
2007-06-26 2:20 ` Neil Brown
2007-06-26 3:20 ` Graeme Sheppard
2007-06-26 3:38 ` Neil Brown
2007-06-26 4:22 ` Graeme Sheppard
2007-06-26 4:33 ` Neil Brown
2007-06-26 16:53 ` Bryan Henderson
2007-06-26 17:38 ` Andreas Dilger
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=46806CCB.6020708@rillion.net \
--to=nodes@rillion.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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).