From: Christoph Hellwig <hch@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: Slava Dubeyko <Vyacheslav.Dubeyko@wdc.com>,
Vishal Verma <vishal.l.verma@intel.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
Viacheslav Dubeyko <slava@dubeyko.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems
Date: Tue, 17 Jan 2017 07:08:09 -0800 [thread overview]
Message-ID: <20170117150809.GA12484@infradead.org> (raw)
In-Reply-To: <20170117143703.GP2517@quack2.suse.cz>
On Tue, Jan 17, 2017 at 03:37:03PM +0100, Jan Kara wrote:
> Well, the situation with NVM is more like with DRAM AFAIU. It is quite
> reliable but given the size the probability *some* cell has degraded is
> quite high. And similar to DRAM you'll get MCE (Machine Check Exception)
> when you try to read such cell. As Vishal wrote, the hardware does some
> background scrubbing and relocates stuff early if needed but nothing is 100%.
Based on publically available papers and little information leaks
there is no persistent NVM that comes even close to the error rate
for DRAM - they all appear to be magnitudes worse.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: Slava Dubeyko <Vyacheslav.Dubeyko@wdc.com>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Viacheslav Dubeyko <slava@dubeyko.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems
Date: Tue, 17 Jan 2017 07:08:09 -0800 [thread overview]
Message-ID: <20170117150809.GA12484@infradead.org> (raw)
In-Reply-To: <20170117143703.GP2517@quack2.suse.cz>
On Tue, Jan 17, 2017 at 03:37:03PM +0100, Jan Kara wrote:
> Well, the situation with NVM is more like with DRAM AFAIU. It is quite
> reliable but given the size the probability *some* cell has degraded is
> quite high. And similar to DRAM you'll get MCE (Machine Check Exception)
> when you try to read such cell. As Vishal wrote, the hardware does some
> background scrubbing and relocates stuff early if needed but nothing is 100%.
Based on publically available papers and little information leaks
there is no persistent NVM that comes even close to the error rate
for DRAM - they all appear to be magnitudes worse.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2017-01-17 15:08 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <at1mp6pou4lenesjdgh22k4p.1484345585589@email.android.com>
[not found] ` <b9rbflutjt10mb4ofherta8j.1484345610771@email.android.com>
2017-01-14 0:00 ` [LSF/MM TOPIC] Badblocks checking/representation in filesystems Slava Dubeyko
2017-01-14 0:00 ` Slava Dubeyko
2017-01-14 0:00 ` Slava Dubeyko
2017-01-14 0:49 ` Vishal Verma
2017-01-14 0:49 ` Vishal Verma
2017-01-16 2:27 ` Slava Dubeyko
2017-01-16 2:27 ` Slava Dubeyko
2017-01-16 2:27 ` Slava Dubeyko
2017-01-17 14:37 ` [Lsf-pc] " Jan Kara
2017-01-17 14:37 ` Jan Kara
2017-01-17 15:08 ` Christoph Hellwig [this message]
2017-01-17 15:08 ` Christoph Hellwig
2017-01-17 22:14 ` Vishal Verma
2017-01-17 22:14 ` Vishal Verma
2017-01-18 10:16 ` Jan Kara
2017-01-18 10:16 ` Jan Kara
2017-01-18 20:39 ` Jeff Moyer
2017-01-18 20:39 ` Jeff Moyer
2017-01-18 21:02 ` Darrick J. Wong
2017-01-18 21:02 ` Darrick J. Wong
2017-01-18 21:32 ` Dan Williams
2017-01-18 21:32 ` Dan Williams
2017-01-18 21:56 ` Verma, Vishal L
2017-01-18 21:56 ` Verma, Vishal L
2017-01-18 21:56 ` Verma, Vishal L
2017-01-19 8:10 ` Jan Kara
2017-01-19 8:10 ` Jan Kara
2017-01-19 18:59 ` Vishal Verma
2017-01-19 18:59 ` Vishal Verma
2017-01-19 19:03 ` Dan Williams
2017-01-19 19:03 ` Dan Williams
2017-01-20 9:03 ` Jan Kara
2017-01-20 9:03 ` Jan Kara
2017-01-17 23:15 ` Slava Dubeyko
2017-01-17 23:15 ` Slava Dubeyko
2017-01-17 23:15 ` Slava Dubeyko
2017-01-18 20:47 ` Jeff Moyer
2017-01-18 20:47 ` Jeff Moyer
2017-01-19 2:56 ` Slava Dubeyko
2017-01-19 2:56 ` Slava Dubeyko
2017-01-19 2:56 ` Slava Dubeyko
2017-01-19 19:33 ` Jeff Moyer
2017-01-19 19:33 ` Jeff Moyer
2017-01-17 6:33 ` Darrick J. Wong
2017-01-17 6:33 ` Darrick J. Wong
2017-01-17 21:35 ` Vishal Verma
2017-01-17 21:35 ` Vishal Verma
2017-01-17 22:15 ` Andiry Xu
2017-01-17 22:15 ` Andiry Xu
2017-01-17 22:37 ` Vishal Verma
2017-01-17 22:37 ` Vishal Verma
2017-01-17 23:20 ` Andiry Xu
2017-01-17 23:20 ` Andiry Xu
2017-01-17 23:51 ` Vishal Verma
2017-01-17 23:51 ` Vishal Verma
2017-01-18 1:58 ` Andiry Xu
2017-01-18 1:58 ` Andiry Xu
2017-01-20 0:32 ` Verma, Vishal L
2017-01-20 0:32 ` Verma, Vishal L
2017-01-20 0:32 ` Verma, Vishal L
2017-01-18 9:38 ` [Lsf-pc] " Jan Kara
2017-01-18 9:38 ` Jan Kara
2017-01-19 21:17 ` Vishal Verma
2017-01-19 21:17 ` Vishal Verma
2017-01-20 9:47 ` Jan Kara
2017-01-20 9:47 ` Jan Kara
2017-01-20 15:42 ` Dan Williams
2017-01-20 15:42 ` Dan Williams
2017-01-24 7:46 ` Jan Kara
2017-01-24 7:46 ` Jan Kara
2017-01-24 19:59 ` Vishal Verma
2017-01-24 19:59 ` Vishal Verma
2017-01-18 0:16 ` Andreas Dilger
2017-01-18 2:01 ` Andiry Xu
2017-01-18 2:01 ` Andiry Xu
2017-01-18 3:08 ` Lu Zhang
2017-01-18 3:08 ` Lu Zhang
2017-01-20 0:46 ` Vishal Verma
2017-01-20 0:46 ` Vishal Verma
2017-01-20 9:24 ` Yasunori Goto
2017-01-20 9:24 ` Yasunori Goto
2017-01-21 0:23 ` Kani, Toshimitsu
2017-01-21 0:23 ` Kani, Toshimitsu
2017-01-21 0:23 ` Kani, Toshimitsu
2017-01-20 0:55 ` Verma, Vishal L
2017-01-20 0:55 ` Verma, Vishal L
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=20170117150809.GA12484@infradead.org \
--to=hch@infradead.org \
--cc=Vyacheslav.Dubeyko@wdc.com \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=slava@dubeyko.com \
--cc=vishal.l.verma@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 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.