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
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
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.
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
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
> 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...
>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.
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?
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
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.
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
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.
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