From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp1050.oracle.com ([141.146.126.70]:47070 "EHLO aserp1050.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752570AbdARWQv (ORCPT ); Wed, 18 Jan 2017 17:16:51 -0500 Date: Wed, 18 Jan 2017 13:02:41 -0800 From: "Darrick J. Wong" To: Jeff Moyer Cc: Jan Kara , Vishal Verma , Slava Dubeyko , "linux-nvdimm@lists.01.org" , "linux-block@vger.kernel.org" , Viacheslav Dubeyko , Linux FS Devel , "lsf-pc@lists.linux-foundation.org" Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems Message-ID: <20170118210241.GE10498@birch.djwong.org> References: <20170114004910.GA4880@omniknight.lm.intel.com> <20170117143703.GP2517@quack2.suse.cz> <20170117221421.GC4880@omniknight.lm.intel.com> <20170118101641.GD24789@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jan 18, 2017 at 03:39:17PM -0500, Jeff Moyer wrote: > Jan Kara writes: > > > On Tue 17-01-17 15:14:21, Vishal Verma wrote: > >> Your note on the online repair does raise another tangentially related > >> topic. Currently, if there are badblocks, writes via the bio submission > >> path will clear the error (if the hardware is able to remap the bad > >> locations). However, if the filesystem is mounted eith DAX, even > >> non-mmap operations - read() and write() will go through the dax paths > >> (dax_do_io()). We haven't found a good/agreeable way to perform > >> error-clearing in this case. So currently, if a dax mounted filesystem > >> has badblocks, the only way to clear those badblocks is to mount it > >> without DAX, and overwrite/zero the bad locations. This is a pretty > >> terrible user experience, and I'm hoping this can be solved in a better > >> way. > > > > Please remind me, what is the problem with DAX code doing necessary work to > > clear the error when it gets EIO from memcpy on write? > > You won't get an MCE for a store; only loads generate them. > > Won't fallocate FL_ZERO_RANGE clear bad blocks when mounted with -o dax? Not necessarily; XFS usually implements this by punching out the range and then reallocating it as unwritten blocks. --D > > Cheers, > Jeff > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html