From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.9]:52176 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750817AbdAQPIM (ORCPT ); Tue, 17 Jan 2017 10:08:12 -0500 Date: Tue, 17 Jan 2017 07:08:09 -0800 From: Christoph Hellwig To: Jan Kara Cc: Slava Dubeyko , Vishal Verma , "linux-block@vger.kernel.org" , Linux FS Devel , "lsf-pc@lists.linux-foundation.org" , Viacheslav Dubeyko , "linux-nvdimm@lists.01.org" Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems Message-ID: <20170117150809.GA12484@infradead.org> References: <20170114004910.GA4880@omniknight.lm.intel.com> <20170117143703.GP2517@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170117143703.GP2517@quack2.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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.