From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.133]:46906 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbeCNQsb (ORCPT ); Wed, 14 Mar 2018 12:48:31 -0400 Date: Wed, 14 Mar 2018 09:48:25 -0700 From: Matthew Wilcox To: Amit Golander Cc: Miklos Szeredi , Amir Goldstein , Amit Golander , Andy Rudof , Anna Schumaker , Boaz Harrosh , Jan Kara , Jefff moyer , Ric Wheeler , Sage Weil , Sagi Manole , Shachar Sharon , Steve French , Steven Whitehouse , linux-fsdevel Subject: Re: [RFC 1/7] mm: Add new vma flag VM_LOCAL_CPU Message-ID: <20180314164825.GI29631@bombadil.infradead.org> References: <443fea57-f165-6bed-8c8a-0a32f72b9cd2@netapp.com> <20180313185658.GB21538@bombadil.infradead.org> <20180314111750.GA29631@bombadil.infradead.org> <20180314114518.GC29631@bombadil.infradead.org> <20180314145719.GH29631@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Mar 14, 2018 at 04:27:20PM +0000, Amit Golander wrote: > ZUFS is not intended or designed to replace FUSE. Just like RDMA is not > intended to replace TCP. Your intent is to have two independent approaches to permitting filesystems-in-userspace to exist. And I've pointed out that your approach doesn't work for my use-case (and neither does FUSE). While we might accept two implementations of something, at the point that three implementations are proposed, we usually say "No, come up with a better solution that works for everybody". > On Wed, 14 Mar 2018 at 8:39 Miklos Szeredi wrote: > > > On Wed, Mar 14, 2018 at 3:57 PM, Matthew Wilcox > > wrote: > > > On Wed, Mar 14, 2018 at 03:49:35PM +0100, Miklos Szeredi wrote: > > >> On Wed, Mar 14, 2018 at 12:45 PM, Matthew Wilcox > > wrote: > > >> > Erm ... there's nothing wrong with having one pipe per CPU. But pipes > > >> > being non-seekable means that ZUFS can only handle synchronous I/Os. > > >> > If you want to have a network backend, then you'd only be able to have > > >> > one outstanding network request per pipe, which is really going to > > suck > > >> > for bandwidth. > > >> > > >> I guess ZUFS is mostly about fast synchronous access (please correct > > >> me if I'm wrong). Not sure that model fits network filesystems, where > > >> performance of caching will dominate real life performance. > > > > > > I'm sure that's Boaz's use case ;-) But if we're introducing > > > a replacement for FUSE, let's make it better than FUSE, not just > > > specialised to Boaz's use case. > > > > Okay, so the FUSE vs. ZUFS question was bound to be raised at some > > point. What's the high level thinking on this? > > > > We can make ZUFS be a better FUSE, but with a new API? New API means > > we'll lose existing user base. Having a new API but adding a compat > > layer may be able to work around that, but it's probably hard to fully > > emulate the old API. > > > > What are the limiting factors in the FUSE API that are preventing > > fixing these performance problems in FUSE? > > > > Or it's just that FUSE kernel implementation is a horrid piece of > > bloat (true) and we need to do something from scratch without worrying > > about backward compat issues? > > > > Is ZUFS planning to acquire a caching layer? > > > > Btw, what is happening when a ZUFS file is mmaped? > > > > Thanks, > > Miklos > >