From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16BE3C43381 for ; Tue, 19 Feb 2019 19:15:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C57712147C for ; Tue, 19 Feb 2019 19:15:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bRFi5BVz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725987AbfBSTP6 (ORCPT ); Tue, 19 Feb 2019 14:15:58 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:56188 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725827AbfBSTP6 (ORCPT ); Tue, 19 Feb 2019 14:15:58 -0500 Received: by mail-wm1-f68.google.com with SMTP id q187so4025089wme.5 for ; Tue, 19 Feb 2019 11:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Uyp3J3bXkfuS8vv8czugnMhbz7LpDaBp/EPhYQtpsHU=; b=bRFi5BVzHX/ST36vVsiPdMq8bUvmtsWTt23eWWMIRqUxRinUgQTpRv44ZzaYOyLzjN LKqi1bs6ynEd8AJpH+7/5md445Jol2pdNSNWiPmLTnT9St20QAEtWSocg4Xh7G4armiV V5mRagMdf0CXhQF/3dp/2nN0006/tCOA9N9TGnVWIHnrvHX1qGqd4BbYBg6v3lmcjnPE B0ptQ6RgS/Sq8rZUWJYtSLpO0jZChTe/VE3cBWRiyALScR9j6dLx1V1fy4+95lFsK+TP YIdHzwtQm2/XQvJQnX+Mf0kvLm6w8uJlbpGMO0Z/+izC8z789UkpjN7hGxVN3jabNQ/g Tmsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Uyp3J3bXkfuS8vv8czugnMhbz7LpDaBp/EPhYQtpsHU=; b=Wdj2MKnd2jzOksri8yY8PS8AVRJEbN61j9gezjIHWp1YZiUR1aVZSfhMisuXJHha/v znxyCocyjZ2bBtXLd5VKn2H/pJKO/+O2HZbdOlEFx6bqC5NB5cYJJpwCisrhJiFK7E14 2X63MgNjtVqRqyo4dgWyYzya9+qlenHJn3xg3j1YWa+w8SPX8pa0vDTO55ug/j4qnapG fmMfxYpqUYodCw8EiJlEUid7wXnys7xMsv1bJNzpdc4+z0irdcBRKiKENBRPqJsqmPUK euQ64sOnUCURA6S00+3gAJZozrvwcmKQyDYPE+ERNSMR+N8USUdM9DhilZ2y2FOj1nyM 0zkg== X-Gm-Message-State: AHQUAuatJDrIRHozX0W2JpzH+9lKMKI1rYgD3Kn4qpvzhHNHE/V3C4kN dE3zHN9A/EcW4WJYhC3z9RM= X-Google-Smtp-Source: AHgI3IblWD0WkYMvapU5xJVY183M8m0IHWvkQOrrOa4HvcRE/ZRr4iUONkWnhw/IMlJZfmB5ubiclQ== X-Received: by 2002:a1c:a104:: with SMTP id k4mr3830801wme.54.1550603755366; Tue, 19 Feb 2019 11:15:55 -0800 (PST) Received: from [10.0.0.5] ([207.232.55.62]) by smtp.gmail.com with ESMTPSA id c18sm20814855wre.32.2019.02.19.11.15.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Feb 2019 11:15:54 -0800 (PST) Subject: Re: [RFC PATCH 00/17] zuf: ZUFS Zero-copy User-mode FileSystem To: Matthew Wilcox , Boaz harrosh References: <20190219115136.29952-1-boaz@plexistor.com> <20190219121503.GZ12668@bombadil.infradead.org> Cc: linux-fsdevel , Anna Schumaker , Al Viro , Ric Wheeler , Miklos Szeredi , Steven Whitehouse , Jefff moyer , Amir Goldstein , Amit Golander , Sagi Manole From: Boaz Harrosh Message-ID: <26544038-4312-7b0f-82ab-6be0ba509a20@gmail.com> Date: Tue, 19 Feb 2019 21:15:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20190219121503.GZ12668@bombadil.infradead.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.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