From: Boaz Harrosh <boaz@plexistor.com>
To: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: [Ksummit-discuss] [TOPIC] ZUFS - Zero Copy User-Mode FileSystem - One year Later
Date: Thu, 8 Nov 2018 21:21:59 +0200 [thread overview]
Message-ID: <823423bc-21f3-7e05-e5f7-a20296974250@plexistor.com> (raw)
Linux Plumbers 2018: ZUFS - Zero Copy User-Mode FileSystem - One year Later
[This is the original pitch]
One year after its inception there are real hardened FSs. Many innovative fixtures.
But is it ready for upstream?
Few highlights:
- ALL VFS api working including dax, mmap IOCTL xattrs ACLs ....
(Missing quota)
- IO API changed (From last year)
- Support for ASYNC operations
- Support for both pmem and regular block devices
- Support for private memory pools
- ZTs multy-channel and dynamic channel allocation
- And many more ...
In the talk I will give a short architectural and functional overview.
Then will go over some of the leftover challenges.
And finally hope to engage in an open discussion of how this project should move forward
to be accepted into the Kernel, gain more users and FS implementations.
[Matthew Wilcox asked what changed]
First of all last year was nothing was just a POC experiment. And At LSF it was only half backed.
Since then we have a real implementation of real FSs. Passing xfstests. Passing QA and ready for
client machines. This called for some changes in API as well as other fixes.
Some highlights.
- The Kernel guys did not like the changes I proposed to elevate the huge performance and
scalability penalty of the VMA *unmap* of application pages into the server. So the IO API
needed to change. (So to keep the same target performance)
- We now support both pmem and block-devices all in the same FS. Including data migration between
the two types.
- We have more threads per core and channels can dynamically be allocated so server may sleep.
We also have a mechanism for locking a channel so not to get to the position of critical
operations starving for a channel.
- Support for ASYNC operations. (Was all low latency SYNC OPs before)
- Lots more little stuff that were not finished before.
- ....
Cheers
Boaz
next reply other threads:[~2018-11-08 19:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-08 19:21 Boaz Harrosh [this message]
2018-11-14 19:14 ` [Ksummit-discuss] [TOPIC] ZUFS - Zero Copy User-Mode FileSystem - One year Later Theodore Y. Ts'o
2018-11-14 19:56 ` Theodore Y. Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=823423bc-21f3-7e05-e5f7-a20296974250@plexistor.com \
--to=boaz@plexistor.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).