linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@kvack.org>
To: Vyacheslav Dubeyko <slava@dubeyko.com>
Cc: Matthew Wilcox <willy@linux.intel.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: NVM Mapping API
Date: Wed, 16 May 2012 17:58:49 -0400	[thread overview]
Message-ID: <20120516215849.GC32221@kvack.org> (raw)
In-Reply-To: <1337149453.1961.24.camel@slavad-ubuntu-11>

On Wed, May 16, 2012 at 10:24:13AM +0400, Vyacheslav Dubeyko wrote:
> Could you please share vision of these NVM technologies in more details?
> What capacity in bytes of of one NVM unit do we can expect? What about
> bad blocks and any other reliability issues of such NVM technologies?
> 
> I think that some more deep understanding of this can give possibility
> to imagine more deeply possible niche of such NVM units in future memory
> subsystem architecture.

Try having a look at the various articles on ReRAM, PRAM, FeRAM, MRAM...  
There are a number of technologies being actively developed.  For some 
quick info, Samsung has presented data on an 8Gbit 20nm device (see 
http://www.eetimes.com/electronics-news/4230958/ISSCC--Samsung-preps-8-Gbit-phase-change-memory ).  
It's hard to predict who will be first to market with a real production 
volume product, though.

The big question I have is what the actual interface for these types of 
memory will be.  If they're like actual RAM and can be mmap()ed into user 
space, it will be preferable to avoid as much of the overhead of the existing 
block infrastructure that most current day filesystems are built on top of.  
If the devices have only modest endurance limits, we may need to stick the 
kernel in the middle to prevent malicious code from wearing out a user's 
memory cells.

		-ben

  parent reply	other threads:[~2012-05-16 21:58 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 [this message]
2012-05-17 19:06     ` Matthew Wilcox
2012-05-16  9:52 ` James Bottomley
2012-05-16 17:35   ` Matthew Wilcox
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=20120516215849.GC32221@kvack.org \
    --to=bcrl@kvack.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=slava@dubeyko.com \
    --cc=willy@linux.intel.com \
    /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).