From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 42A1081787 for ; Tue, 17 Jan 2017 07:08:13 -0800 (PST) Date: Tue, 17 Jan 2017 07:08:09 -0800 From: Christoph Hellwig 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-Disposition: inline In-Reply-To: <20170117143703.GP2517@quack2.suse.cz> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Jan Kara Cc: Slava Dubeyko , "linux-nvdimm@lists.01.org" , "linux-block@vger.kernel.org" , Viacheslav Dubeyko , Linux FS Devel , "lsf-pc@lists.linux-foundation.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. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm