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 <mszeredi@xxxxxxxxxx> wrote: > > > On Wed, Mar 14, 2018 at 3:57 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> > > 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 <willy@xxxxxxxxxxxxx> > > 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 > >
