Re: Patent or not patent a new idea
Neil Brown wrote: ??? (reads original description in more detail). So... the filesystem images are identical in both copies, and the "interesting" bit is that the image is just a file on some filesystem. So could I implement your idea by: dd if=/dev/zero of=/1/bigfile count=lotsandlots dd if=/dev/zero of=/2/bigfile count=lotsandlots losetup /dev/loop1 /1/bigfile losetup /dev/loop2 /2/bigfile mdadm -C /dev/md0 --level=raid1 --raid-disks=2 /dev/loop1 /dev/loop2 mkfs /dev/md0 mount /dev/md2 /space ?? Why would you bother? Well, I do it a lot of code testing, but I would be hard pressed to make a case for that sort of config in production. Thanks for the brief howto there. I'll install the mdadm suite and experiment. It seems like a userspace driver? You said: 1) the disks need not be the same size or from the same manufacturer; 2) the supporting code would be cross-platform. md/raid already works happily with different sized drives from different manufacturers (for raid1, it only uses as much space as the smaller drive provides, For raid0 it uses it all). I don't know what you mean by '2'. 2 meant in the way that a driver for a PC raid card is not much use on a Sparc. So I still cannot see anything particularly new. What am I missing? I think it's what I missed. Thanks for the heads-up. If the above is a good technique it could suit me well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patent or not patent a new idea
Neil Brown wrote: On Tuesday June 26, [EMAIL PROTECTED] wrote: 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. Sounds a lot like "RAIF" - ask google for details. I did not know about RAIF. RAIF "merges" separate filesystems? That is a good idea in itself. My idea is for driver that provides a filesystem from image files it controls. Because it knows these resources it uses access in tandem to attain performance. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patent or not patent a new idea
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patent or not patent a new idea
alan wrote: On Tue, 26 Jun 2007, Graeme Sheppard wrote: Dear devs, In a moment of serendipity I thought of a concept which may be advantageous if incorporated into the kernel. I was going to offer it to the OIN but they responded they only consider existing patents and I don't have the money to afford one. How do you know it is a new idea? The essence of the idea is simple enough that I would have heard of it. It isn't an arcane programming trick buried deep in code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patent or not patent a new idea
Dear devs, In a moment of serendipity I thought of a concept which may be advantageous if incorporated into the kernel. I was going to offer it to the OIN but they responded they only consider existing patents and I don't have the money to afford one. I am seeking advice on how to proceed. It could be used as a defensive patent in which case I can email an expert who can file it. If that is the concept is sound. I am not expecting any royalties from this myself. The alternative is to dump it here to the LKML. It should be said I'm not a kernel coder and if I attempted this I would probably do it wrong. The concept is a different way to attain performance. The area pertaining is filesystems. Not wishing to overstate things lest the flames scorching a bad idea get too hot. Regards, Graeme - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patent or not patent a new idea
Dear devs, In a moment of serendipity I thought of a concept which may be advantageous if incorporated into the kernel. I was going to offer it to the OIN but they responded they only consider existing patents and I don't have the money to afford one. I am seeking advice on how to proceed. It could be used as a defensive patent in which case I can email an expert who can file it. If that is the concept is sound. I am not expecting any royalties from this myself. The alternative is to dump it here to the LKML. It should be said I'm not a kernel coder and if I attempted this I would probably do it wrong. The concept is a different way to attain performance. The area pertaining is filesystems. Not wishing to overstate things lest the flames scorching a bad idea get too hot. Regards, Graeme - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patent or not patent a new idea
alan wrote: On Tue, 26 Jun 2007, Graeme Sheppard wrote: Dear devs, In a moment of serendipity I thought of a concept which may be advantageous if incorporated into the kernel. I was going to offer it to the OIN but they responded they only consider existing patents and I don't have the money to afford one. How do you know it is a new idea? The essence of the idea is simple enough that I would have heard of it. It isn't an arcane programming trick buried deep in code. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patent or not patent a new idea
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patent or not patent a new idea
Neil Brown wrote: On Tuesday June 26, [EMAIL PROTECTED] wrote: 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. Sounds a lot like RAIF - ask google for details. I did not know about RAIF. RAIF merges separate filesystems? That is a good idea in itself. My idea is for driver that provides a filesystem from image files it controls. Because it knows these resources it uses access in tandem to attain performance. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patent or not patent a new idea
Neil Brown wrote: ??? (reads original description in more detail). So... the filesystem images are identical in both copies, and the interesting bit is that the image is just a file on some filesystem. So could I implement your idea by: dd if=/dev/zero of=/1/bigfile count=lotsandlots dd if=/dev/zero of=/2/bigfile count=lotsandlots losetup /dev/loop1 /1/bigfile losetup /dev/loop2 /2/bigfile mdadm -C /dev/md0 --level=raid1 --raid-disks=2 /dev/loop1 /dev/loop2 mkfs /dev/md0 mount /dev/md2 /space ?? Why would you bother? Well, I do it a lot of code testing, but I would be hard pressed to make a case for that sort of config in production. Thanks for the brief howto there. I'll install the mdadm suite and experiment. It seems like a userspace driver? You said: 1) the disks need not be the same size or from the same manufacturer; 2) the supporting code would be cross-platform. md/raid already works happily with different sized drives from different manufacturers (for raid1, it only uses as much space as the smaller drive provides, For raid0 it uses it all). I don't know what you mean by '2'. 2 meant in the way that a driver for a PC raid card is not much use on a Sparc. So I still cannot see anything particularly new. What am I missing? I think it's what I missed. Thanks for the heads-up. If the above is a good technique it could suit me well. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
