From: Boaz Harrosh <openosd@gmail.com>
To: Matthew Wilcox <willy@infradead.org>, Boaz harrosh <boaz@plexistor.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Anna Schumaker <Anna.Schumaker@netapp.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Ric Wheeler <rwheeler@redhat.com>,
Miklos Szeredi <mszeredi@redhat.com>,
Steven Whitehouse <swhiteho@redhat.com>,
Jefff moyer <jmoyer@redhat.com>,
Amir Goldstein <amir73il@gmail.com>,
Amit Golander <Amit.Golander@netapp.com>,
Sagi Manole <sagim@netapp.com>
Subject: Re: [RFC PATCH 00/17] zuf: ZUFS Zero-copy User-mode FileSystem
Date: Tue, 19 Feb 2019 21:15:52 +0200 [thread overview]
Message-ID: <26544038-4312-7b0f-82ab-6be0ba509a20@gmail.com> (raw)
In-Reply-To: <20190219121503.GZ12668@bombadil.infradead.org>
On 19/02/19 14:15, Matthew Wilcox wrote:
> On Tue, Feb 19, 2019 at 01:51:19PM +0200, Boaz harrosh wrote:
>> Please see first patch for License of this project
>>
>> Current status: There are a couple of trivial open-source filesystem
>> implementations and a full blown proprietary implementation from Netapp.
>
> I regard this patchset as being an attempt to avoid your obligations
> under the GPL. As such, I will not be reviewing this code and I oppose
> its inclusion.
>
Dearest Matthew
One day We'll sit on a bear and you explain to me. I do trust your
opinion, but I do not understand.
Specifically the above "full blown proprietary implementation from Netapp"
does not break the GPL at all. Parts of it are written in languages alien
to the Kernel and parts using user-mode libs and code IP that are not able
to live in the Kernel. At the beginning we had code to inject the FS into
the application of choice vi ld.so and only selected apps like a DB would
have a view of the filesystem. But you can imagine how this is a nightmare
for IT. Being POSIX under the Kernel is just so much less inventing the wheel
say: backup, disaster-recovery, cloud ....
Now actually if you look at the code submitted you will see that we are using
very very little out of the Kernel. Actually for comparison FUSE is using the
Kernel much heavier. Utilizing page-cache, Kernel re-claimers. Smart write-back
the lot. In ZUFS we take the upper most interfaces and send it down stream as is.
Where ever there is depth of stack we take the top most level and push that to
server as is completely synchronous to the app threads.
The only real novelty in this project is something completely new to this
submission, it is the new RPC we invented here that utilizes per-cpu Technics
to show a kind of performance never seen before between two processes.
You are a Kernel contributor, you have IP in the Kernel. Your opinion is very
important to me and to Netapp. Please point me to these areas that you feel
I have stepped on your IP, and have not respected the GPL? And I would want
very much to fix it.
Or maybe my sin is that I am to successful? Is the GPL guarded by speed?
I mean say FUSE it is already doing all these sins. And or other subsystems
that bridge Kernel functionality to user-mode. There are other user-mode
"drivers" all over the place. But they are all so slooooooow. So a serious
FS or server needs to sit in Kernel. With zufs we can now delegate to user-mode.
The kernel becomes a micro-kernel, very-fast-bridge, and moves out of the way.
Creating space for serious servers to sit in userland.
To summarize. I take your statement very seriously. Please state what service
of the GPLed Kernel am I exposing and circumventing and I will want to fix it ASAP.
I thought, and my philosophy was to take the POSIX interfaces as high as possible
and shove them to userland. In an RPC manner that I invented that is very fast.
If there are such areas that I am not doing so. Please show me?
Best regards
Boaz
prev parent reply other threads:[~2019-02-19 19:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-19 11:51 [RFC PATCH 00/17] zuf: ZUFS Zero-copy User-mode FileSystem Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 01/17] fs: Add the ZUF filesystem to the build + License Boaz harrosh
2019-02-20 11:03 ` Greg KH
2019-02-20 14:55 ` Boaz Harrosh
2019-02-20 19:40 ` Greg KH
2019-02-26 17:55 ` Schumaker, Anna
2019-02-28 16:42 ` Boaz Harrosh
2019-02-19 11:51 ` [RFC PATCH 02/17] zuf: Preliminary Documentation Boaz harrosh
2019-02-20 8:27 ` Miklos Szeredi
2019-02-20 14:24 ` Boaz Harrosh
2019-02-19 11:51 ` [RFC PATCH 03/17] zuf: zuf-rootfs Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 04/17] zuf: zuf-core The ZTs Boaz harrosh
2019-02-26 18:34 ` Schumaker, Anna
2019-02-28 17:01 ` Boaz Harrosh
2019-02-19 11:51 ` [RFC PATCH 05/17] zuf: Multy Devices Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 06/17] zuf: mounting Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 07/17] zuf: Namei and directory operations Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 08/17] zuf: readdir operation Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 09/17] zuf: symlink Boaz harrosh
2019-02-20 11:05 ` Greg KH
2019-02-20 14:12 ` Boaz Harrosh
2019-02-19 11:51 ` [RFC PATCH 10/17] zuf: More file operation Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 11/17] zuf: Write/Read implementation Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 12/17] zuf: mmap & sync Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 13/17] zuf: ioctl implementation Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 14/17] zuf: xattr implementation Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 15/17] zuf: ACL support Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 16/17] zuf: Special IOCTL fadvise (TODO) Boaz harrosh
2019-02-19 11:51 ` [RFC PATCH 17/17] zuf: Support for dynamic-debug of zusFSs Boaz harrosh
2019-02-19 12:15 ` [RFC PATCH 00/17] zuf: ZUFS Zero-copy User-mode FileSystem Matthew Wilcox
2019-02-19 19:15 ` Boaz Harrosh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26544038-4312-7b0f-82ab-6be0ba509a20@gmail.com \
--to=openosd@gmail.com \
--cc=Amit.Golander@netapp.com \
--cc=Anna.Schumaker@netapp.com \
--cc=amir73il@gmail.com \
--cc=boaz@plexistor.com \
--cc=jmoyer@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mszeredi@redhat.com \
--cc=rwheeler@redhat.com \
--cc=sagim@netapp.com \
--cc=swhiteho@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).