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
