From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:43383 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752632AbdARKQ5 (ORCPT ); Wed, 18 Jan 2017 05:16:57 -0500 Date: Wed, 18 Jan 2017 11:16:41 +0100 From: Jan Kara To: Vishal Verma Cc: Jan Kara , Slava Dubeyko , "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: <20170118101641.GD24789@quack2.suse.cz> References: <20170114004910.GA4880@omniknight.lm.intel.com> <20170117143703.GP2517@quack2.suse.cz> <20170117221421.GC4880@omniknight.lm.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20170117221421.GC4880@omniknight.lm.intel.com> Sender: linux-block-owner@vger.kernel.org List-Id: linux-block@vger.kernel.org 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? Honza -- Jan Kara SUSE Labs, CR From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 53E0881E10 for ; Wed, 18 Jan 2017 02:16:46 -0800 (PST) Date: Wed, 18 Jan 2017 11:16:41 +0100 From: Jan Kara Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems Message-ID: <20170118101641.GD24789@quack2.suse.cz> References: <20170114004910.GA4880@omniknight.lm.intel.com> <20170117143703.GP2517@quack2.suse.cz> <20170117221421.GC4880@omniknight.lm.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170117221421.GC4880@omniknight.lm.intel.com> 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: Vishal Verma Cc: Jan Kara , 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 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? Honza -- Jan Kara SUSE Labs, CR _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm