From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kent Overstreet Subject: Re: scrub backing device Date: Fri, 13 May 2016 14:21:33 -0800 Message-ID: <20160513222133.GA3784@kmo-pixel> References: <20160511235748.GR18290@merlins.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pa0-f68.google.com ([209.85.220.68]:36679 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753538AbcEMWVh (ORCPT ); Fri, 13 May 2016 18:21:37 -0400 Received: by mail-pa0-f68.google.com with SMTP id i5so9394452pag.3 for ; Fri, 13 May 2016 15:21:37 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20160511235748.GR18290@merlins.org> Sender: linux-bcache-owner@vger.kernel.org List-Id: linux-bcache@vger.kernel.org To: Marc MERLIN Cc: ching , Eric Wheeler , linux-bcache@vger.kernel.org On Wed, May 11, 2016 at 04:57:48PM -0700, Marc MERLIN wrote: > On Thu, May 12, 2016 at 07:34:26AM +0800, ching wrote: > > for example https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub > > btrfs scrub is designed to make sure all the blocks and checksums are > consistent. > Ching makes a good point that it would be helpful to have a way to > access the underlying backing device directly to ensure it is > consistent. > > I think currently you can use dmsetup with an offset to get the real > filesystem past the bcache header, mount that read only somewhere and > scrub that. > Not ideal because scrub will not be able to fix issues that are fixable, > but at least it should report errors. Look at the verify code in drivers/md/bcache/debug.c, there's a CONFIG_BCACHE_DEBUG mode where every time it reads clean cached data it reads the data from the backing device and compares. But for a scrub though you really want to walk all the _cached_ data, so it'd take a bit more code than that.