Re: Patent or not patent a new idea
On Jun 26, 2007 09:53 -0700, Bryan Henderson wrote: > >md/raid already works happily with different sized drives from > >different manufacturers ... > > >So I still cannot see anything particularly new. > > As compared to md of conventional disk partitions, it brings the ability > to create and delete arrays without shutting down all use of the physical > disks (to update the partition tables). (LVM gives you that too). It > also makes managing space much easier because the component devices don't > have to be carved from contiguous space on the physical disks. > > Neither of those benefits is specific to RAID, but you could probably say > that RAID multiplies the problems they address. That's one of the reasons why I liked AIX doing RAID1 on top of LVM. It was possible to safely migrate LEs across disks by virtue of creating a RAID 1 mirror for that LE and then deleting the old copy. It wouldn't be too hard to extend the same notion to RAID 5 or RAID 6 on LVM. You could even change the RAID level and number of constituent LEs in a RAID set on an ad-hoc basis because the LVM mappings would allow this to be efficient. Unfortunately, Linux still has distinct DM and MD layers and there doesn't seem to be any work to combine the two into a more powerful single layer. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patent or not patent a new idea
>md/raid already works happily with different sized drives from >different manufacturers ... >So I still cannot see anything particularly new. As compared to md of conventional disk partitions, it brings the ability to create and delete arrays without shutting down all use of the physical disks (to update the partition tables). (LVM gives you that too). It also makes managing space much easier because the component devices don't have to be carved from contiguous space on the physical disks. Neither of those benefits is specific to RAID, but you could probably say that RAID multiplies the problems they address. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patent or not patent a new idea
On Tuesday June 26, [EMAIL PROTECTED] wrote: > > Thanks for the brief howto there. I'll install the mdadm suite and > experiment. It seems like a userspace driver? mdadm is a userspace tool for managing the 'md' driver which is in the linux kernel. > > 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. Ahh... That is one of the great things about Linux. You code in C, and the driver works on every architecture (providing you are reasonably careful, and the arch actually supports the hardware). :-) NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patent or not patent a new idea
On Tuesday June 26, [EMAIL PROTECTED] wrote: > Neil Brown wrote: > > > > 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. ??? (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. 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'. So I still cannot see anything particularly new. What am I missing? NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patent or not patent a new idea
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. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patent or not patent a new idea
>If your only purpose is to try generate a defensive patent, then just >dumping the idea in the public domain serves the same purpose, probably >better. > >I have a few patents, some of which are defensive. That has not prevented >the USPTO issuing quite a few patents that are in clear violation of mine. That's not what a defensive patent is. Indeed, patenting something just so someone else can't patent it is ridiculous, because publishing is so much easier. A defensive patent is one you file so that you can trade rights to it for rights to other patents that you need. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 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. If your only purpose is to try generate a defensive patent, then just dumping the idea in the public domain serves the same purpose, probably better. I have a few patents, some of which are defensive. That has not prevented the USPTO issuing quite a few patents that are in clear violation of mine. A defensive patent clearly did not prevent these patents from being issued. A defensive patent might make it slightly easier to protect yourself should one of the later patents try flex their muscle, but an idea that is well articulated in a public forum should be sufficient protection too. AINAL and all that... - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patent or not patent a new idea
On Tue, 26 Jun 2007 09:45:22 +1200 Graeme Sheppard <[EMAIL PROTECTED]> wrote: > 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. Do what anyone with a little bit of brain would do: publish it[1]! Patenting it and using as defensive patent wont work. Unless you are able to control Saurons Ring. If you want to know more just read up on current patent practice. IEEE has quite a few articles on that issue, i'm sure that ACM and the like should have also a few. Attila Kinali [1] I know of at least one larger company here that stopped issuing patents but publishes its developments in a local newspaper. -- Linux ist... wenn man einfache Dinge auch mit einer kryptischen post-fix Sprache loesen kann -- Daniel Hottinger - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patent or not patent a new idea
On Tue, 26 Jun 2007, Graeme Sheppard wrote: 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. I have heard that applied to cryptography. In almost every case someone has thought of it already and there is a good reason it is not used. Don't think that it is new and novel until you have done a whole lot of research in the field. There is a reason that the Greeks considered Hubris a sin against the Gods... As for "defensive patents", I think of them as a time bomb waiting to happen. The company that files a defensive patent is rarely the problem, it is when they go broke and someone with less ethics buys them up. The second company does not feel bound by those previous agreements and tries to squeeze all the money they can out of the purchaced patent pool. It may seem like a good idea now, but it comes back to haunt the rest of us later on down the road. -- "ANSI C says access to the padding fields of a struct is undefined. ANSI C also says that struct assignment is a memcpy. Therefore struct assignment in ANSI C is a violation of ANSI C..." - Alan Cox - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patent or not patent a new idea
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? -- "ANSI C says access to the padding fields of a struct is undefined. ANSI C also says that struct assignment is a memcpy. Therefore struct assignment in ANSI C is a violation of ANSI C..." - Alan Cox - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
