From: Matthew Wilcox <willy@linux.intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: NVM Mapping API
Date: Wed, 16 May 2012 13:35:23 -0400 [thread overview]
Message-ID: <20120516173523.GK22985@linux.intel.com> (raw)
In-Reply-To: <1337161920.2985.32.camel@dabdike.int.hansenpartnership.com>
On Wed, May 16, 2012 at 10:52:00AM +0100, James Bottomley wrote:
> On Tue, 2012-05-15 at 09:34 -0400, Matthew Wilcox wrote:
> > There are a number of interesting non-volatile memory (NVM) technologies
> > being developed. Some of them promise DRAM-comparable latencies and
> > bandwidths. At Intel, we've been thinking about various ways to present
> > those to software. This is a first draft of an API that supports the
> > operations we see as necessary. Patches can follow easily enough once
> > we've settled on an API.
>
> If we start from first principles, does this mean it's usable as DRAM?
> Meaning do we even need a non-memory API for it? The only difference
> would be that some pieces of our RAM become non-volatile.
I'm not talking about a specific piece of technology, I'm assuming that
one of the competing storage technologies will eventually make it to
widespread production usage. Let's assume what we have is DRAM with a
giant battery on it.
So, while we can use it just as DRAM, we're not taking advantage of the
persistent aspect of it if we don't have an API that lets us find the
data we wrote before the last reboot. And that sounds like a filesystem
to me.
> Or is there some impediment (like durability, or degradation on rewrite)
> which makes this unsuitable as a complete DRAM replacement?
The idea behind using a different filesystem for different NVM types is
that we can hide those kinds of impediments in the filesystem. By the
way, did you know DRAM degrades on every write? I think it's on the
order of 10^20 writes (and CPU caches hide many writes to heavily-used
cache lines), so it's a long way away from MLC or even SLC rates, but
it does exist.
> Alternatively, if it's not really DRAM, I think the UNIX file
> abstraction makes sense (it's a piece of memory presented as something
> like a filehandle with open, close, seek, read, write and mmap), but
> it's less clear that it should be an actual file system. The reason is
> that to present a VFS interface, you have to already have fixed the
> format of the actual filesystem on the memory because we can't nest
> filesystems (well, not without doing artificial loopbacks). Again, this
> might make sense if there's some architectural reason why the flash
> region has to have a specific layout, but your post doesn't shed any
> light on this.
We can certainly present a block interface to allow using unmodified
standard filesystems on top of chunks of this NVM. That's probably not
the optimum way for a filesystem to use it though; there's really no
point in constructing a bio to carry data down to a layer that's simply
going to do a memcpy().
next prev parent reply other threads:[~2012-05-16 17:35 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 13:34 NVM Mapping API Matthew Wilcox
2012-05-15 17:46 ` Greg KH
2012-05-16 15:57 ` Matthew Wilcox
2012-05-18 12:07 ` Marco Stornelli
2012-05-15 23:02 ` Andy Lutomirski
2012-05-16 16:02 ` Matthew Wilcox
2012-05-31 17:53 ` Andy Lutomirski
2012-05-16 6:24 ` Vyacheslav Dubeyko
2012-05-16 16:10 ` Matthew Wilcox
2012-05-17 9:06 ` Vyacheslav Dubeyko
2012-05-16 21:58 ` Benjamin LaHaise
2012-05-17 19:06 ` Matthew Wilcox
2012-05-16 9:52 ` James Bottomley
2012-05-16 17:35 ` Matthew Wilcox [this message]
2012-05-16 19:58 ` Christian Stroetmann
2012-05-19 22:19 ` Christian Stroetmann
2012-05-17 9:54 ` James Bottomley
2012-05-17 18:59 ` Matthew Wilcox
2012-05-18 9:03 ` James Bottomley
2012-05-18 10:13 ` Boaz Harrosh
2012-05-18 14:49 ` Matthew Wilcox
2012-05-18 15:08 ` Alan Cox
2012-05-18 15:31 ` James Bottomley
2012-05-18 17:19 ` Matthew Wilcox
2012-05-16 13:04 ` Boaz Harrosh
2012-05-16 18:33 ` Matthew Wilcox
2012-05-18 9:33 ` Arnd Bergmann
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=20120516173523.GK22985@linux.intel.com \
--to=willy@linux.intel.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 NNTP newsgroup(s).