From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Phillips <daniel@phunq.net>
Subject: Re: [FYI] tux3: Core changes
Date: Fri, 31 Jul 2015 17:16:45 -0700
Message-ID: <fac9bd94-19a5-498e-ad9e-ed079cd683e3@phunq.net>
References: <alpine.DEB.2.02.1505252303120.3147@nftneq.ynat.uz>
 <67294911-1776-46b8-916d-0e5642a38725@phunq.net>
 <20150526070910.GA3307@quack.suse.cz>
 <a2233e75-a0bc-4732-9d6f-ad4d7cde0bae@phunq.net>
 <20150526090058.GA8024@quack.suse.cz> <5564D60E.6000306@phunq.net>
 <20150527084138.GD2590@quack.suse.cz> <87a8vtdqfz.fsf@mail.parknet.co.jp>
 <20150623161247.GP2427@quack.suse.cz> <87k2ueepd6.fsf@mail.parknet.co.jp>
 <20150709160528.GK2900@quack.suse.cz> <874mklaqbn.fsf@mail.parknet.co.jp>
 <CAGDaZ_oa7BY=70-7CGKoCFqnXbQjYVZ5pCurXh+FaGyKSv2Feg@mail.gmail.com>
 <1981a91e-30a9-43ce-9a05-14aa777e46a5@phunq.net>
 <alpine.DEB.2.02.1507311124390.11360@nftneq.ynat.uz>
 <be97231f-c972-4ec8-b043-f3ca4b1dc42a@phunq.net>
 <alpine.DEB.2.02.1507311524210.11360@nftneq.ynat.uz>
 <b92f9d0c-21b4-4ee0-a086-c984a3785284@phunq.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Rik van Riel <riel@redhat.com>, Jan Kara <jack@suse.cz>, tux3@tux3.org,
 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 linux-fsdevel@vger.kernel.org, OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: David Lang <david@lang.hm>
Return-path: <tux3-bounces@phunq.net>
In-Reply-To: <b92f9d0c-21b4-4ee0-a086-c984a3785284@phunq.net>
List-Unsubscribe: <http://phunq.net/mailman/options/tux3>,
 <mailto:tux3-request@phunq.net?subject=unsubscribe>
List-Archive: <http://phunq.net/pipermail/tux3/>
List-Post: <mailto:tux3@phunq.net>
List-Help: <mailto:tux3-request@phunq.net?subject=help>
List-Subscribe: <http://phunq.net/mailman/listinfo/tux3>,
 <mailto:tux3-request@phunq.net?subject=subscribe>
Errors-To: tux3-bounces@phunq.net
Sender: "Tux3" <tux3-bounces@phunq.net>
List-Id: linux-fsdevel.vger.kernel.org

On Friday, July 31, 2015 5:00:43 PM PDT, Daniel Phillips wrote:
> Note: Hirofumi's email is clear, logical and speaks to the
> question. This branch of the thread is largely pointless, though
> it essentially says the same thing in non-technical terms. Perhaps
> your next response should be to Hirofumi, and perhaps it should be
> technical.

Now, let me try to lead the way, but being specific. RDMA was raised
as a potential failure case for Tux3 page forking. But the RDMA api
does not let you use memory mmaped by Tux3 as a source or destination
of IO. Instead, it sets up its own pages and hands them out to the
RDMA app from a pool. So no issue. One down, right?

Regards,

Daniel