From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Sheppard Subject: Re: Patent or not patent a new idea Date: Tue, 26 Jun 2007 13:32:59 +1200 Message-ID: <46806CCB.6020708@rillion.net> References: <46803772.7020408@rillion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org To: linux-kernel@vger.kernel.org Return-path: Received: from server.rillion.net ([207.210.78.215]:36190 "EHLO rillion.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751001AbXFZBdP (ORCPT ); Mon, 25 Jun 2007 21:33:15 -0400 In-Reply-To: <46803772.7020408@rillion.net> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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?