From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Andiry Xu <andiry@gmail.com>
Cc: lsf-pc@lists.linux-foundation.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
dan.j.williams@intel.com, david@fromorbit.com,
willy@infradead.org, swanson@cs.ucsd.edu, jix024@cs.ucsd.edu
Subject: Re: [LSF/MM TOPIC] Native NVMM file systems
Date: Wed, 31 Jan 2018 17:47:49 -0800 [thread overview]
Message-ID: <20180201014749.GF4841@magnolia> (raw)
In-Reply-To: <CAOvWMLZVkQ1D=Jn-_O9owewr7U699bN=dmwuBoDnQVLEkkXJ8A@mail.gmail.com>
On Wed, Jan 31, 2018 at 04:45:36PM -0800, Andiry Xu wrote:
> PMEM/DAX should allow for significant improvements in file system
> performance and enable new programming models that allow direct,
> efficient access to PMEM from userspace. Achieving these gains in
> existing file systems built for block devices (e.g., XFS and EXT4…)
> presents a range of challenges (e.g.,
> https://lkml.org/lkml/2016/9/11/159) and has been the subject of a lot
> of recent work on ext4 and xfs.
>
> An alternative is to build a NVMM-aware file system from scratch that
> takes full advantage of the performance that PMEM offers and avoids
> the complexity that block-based file systems include to maximize
> performance on slow storage (e.g., relaxing atomicity constraints on
> many operations). Of course, it also brings with it the complexity of
> another file system.
>
> We recently sent out a patch set for one-such “clean slate” NVMM-aware
> file system called NOVA. NOVA is log-structured DAX file system with
> several nice features:
That's the series that was sent out last August, correct?
> * High performance, especially in metadata operations due to efficient
> fine-grained logging
> * High scalability with per-CPU memory pool and per-inode logging
> * Strong metadata and data atomicity guarantees for all operations
> * Full filesystem snapshot support with DAX-mmap
> * Metadata replication/checksums and RAID-4 style data protection
>
> At the summit, we would like to discuss the trade-offs between
> adapting NVMM features to existing file systems vs. creating/adopting
> a purpose-built file system for NVMM. NOVA serves as useful starting
> point for that discussion by demonstrating what’s possible. It may
> also suggest some features that could be adapted to other file systems
> to improve NVMM performance.
>
> We welcome people that are interested in file systems and NVM/DAX.
> Particular people that would be useful to have in attendance are Dan
> Williams, Dave Chinner, and Matthew Wilcox.
I wouldn't mind being there too. :)
--D
>
> Thanks,
> Andiry
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Andiry Xu <andiry@gmail.com>
Cc: lsf-pc@lists.linux-foundation.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
dan.j.williams@intel.com, david@fromorbit.com,
willy@infradead.org, swanson@cs.ucsd.edu, jix024@cs.ucsd.edu
Subject: Re: [LSF/MM TOPIC] Native NVMM file systems
Date: Wed, 31 Jan 2018 17:47:49 -0800 [thread overview]
Message-ID: <20180201014749.GF4841@magnolia> (raw)
In-Reply-To: <CAOvWMLZVkQ1D=Jn-_O9owewr7U699bN=dmwuBoDnQVLEkkXJ8A@mail.gmail.com>
On Wed, Jan 31, 2018 at 04:45:36PM -0800, Andiry Xu wrote:
> PMEM/DAX should allow for significant improvements in file system
> performance and enable new programming models that allow direct,
> efficient access to PMEM from userspace. Achieving these gains in
> existing file systems built for block devices (e.g., XFS and EXT4a?|)
> presents a range of challenges (e.g.,
> https://lkml.org/lkml/2016/9/11/159) and has been the subject of a lot
> of recent work on ext4 and xfs.
>
> An alternative is to build a NVMM-aware file system from scratch that
> takes full advantage of the performance that PMEM offers and avoids
> the complexity that block-based file systems include to maximize
> performance on slow storage (e.g., relaxing atomicity constraints on
> many operations). Of course, it also brings with it the complexity of
> another file system.
>
> We recently sent out a patch set for one-such a??clean slatea?? NVMM-aware
> file system called NOVA. NOVA is log-structured DAX file system with
> several nice features:
That's the series that was sent out last August, correct?
> * High performance, especially in metadata operations due to efficient
> fine-grained logging
> * High scalability with per-CPU memory pool and per-inode logging
> * Strong metadata and data atomicity guarantees for all operations
> * Full filesystem snapshot support with DAX-mmap
> * Metadata replication/checksums and RAID-4 style data protection
>
> At the summit, we would like to discuss the trade-offs between
> adapting NVMM features to existing file systems vs. creating/adopting
> a purpose-built file system for NVMM. NOVA serves as useful starting
> point for that discussion by demonstrating whata??s possible. It may
> also suggest some features that could be adapted to other file systems
> to improve NVMM performance.
>
> We welcome people that are interested in file systems and NVM/DAX.
> Particular people that would be useful to have in attendance are Dan
> Williams, Dave Chinner, and Matthew Wilcox.
I wouldn't mind being there too. :)
--D
>
> Thanks,
> Andiry
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-02-01 1:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 0:45 [LSF/MM TOPIC] Native NVMM file systems Andiry Xu
2018-02-01 0:45 ` Andiry Xu
2018-02-01 1:03 ` Dan Williams
2018-02-01 1:03 ` Dan Williams
2018-02-01 1:13 ` Dan Williams
2018-02-07 10:41 ` Jan Kara
2018-02-07 10:41 ` Jan Kara
2018-02-01 1:47 ` Darrick J. Wong [this message]
2018-02-01 1:47 ` Darrick J. Wong
2018-02-01 2:12 ` Andiry Xu
2018-02-01 2:12 ` Andiry Xu
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=20180201014749.GF4841@magnolia \
--to=darrick.wong@oracle.com \
--cc=andiry@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=jix024@cs.ucsd.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=swanson@cs.ucsd.edu \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.