Message-ID: <46806CCB.6020708@rillion.net>
Date: Tue, 26 Jun 2007 13:32:59 +1200
From: Graeme Sheppard <nodes@rillion.net>
User-Agent: Thunderbird 2.0.0.4 (X11/20070616)
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
CC: linux-fsdevel@vger.kernel.org
Subject: Re: Patent or not patent a new idea
References: <46803772.7020408@rillion.net>
In-Reply-To: <46803772.7020408@rillion.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2006
Lines: 43

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?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/