From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f46.google.com ([209.85.215.46]:36451 "EHLO mail-lf0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751311AbcK1DxG (ORCPT ); Sun, 27 Nov 2016 22:53:06 -0500 Received: by mail-lf0-f46.google.com with SMTP id t196so86854163lff.3 for ; Sun, 27 Nov 2016 19:53:05 -0800 (PST) Subject: Re: [PATCH] btrfs: raid56: Use correct stolen pages to calculate P/Q To: Christoph Anton Mitterer , kreijack@inwind.it, Zygo Blaxell References: <20161121085016.7148-1-quwenruo@cn.fujitsu.com> <94606bda-dab0-e7c9-7fc6-1af9069b64fc@inwind.it> <20161125043119.GG8685@hungrycats.org> <1480304269.6254.6.camel@scientia.net> Cc: Qu Wenruo , linux-btrfs@vger.kernel.org From: Andrei Borzenkov Message-ID: Date: Mon, 28 Nov 2016 06:53:02 +0300 MIME-Version: 1.0 In-Reply-To: <1480304269.6254.6.camel@scientia.net> Content-Type: text/plain; charset=utf-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: 28.11.2016 06:37, Christoph Anton Mitterer пишет: > On Sat, 2016-11-26 at 14:12 +0100, Goffredo Baroncelli wrote: >> I cant agree. If the filesystem is mounted read-only this behavior >> may be correct; bur in others cases I don't see any reason to not >> correct wrong data even in the read case. If your ram is unreliable >> you have big problem anyway. > > I'd agree with that - more or less. > > If the memory is broken, then even without repairing (on read) a > filesystem that is written to will likely be further corrupted. > > > I think for safety it's best to repair as early as possible (and thus > on read when a damage is detected), as further blocks/devices may fail > till eventually a scrub(with repair) would be run manually. > > However, there may some workloads under which such auto-repair is > undesirable as it may cost performance and safety may be less important > than that. > > Thus I think, there should be a mount-option that let users control > whether repair should happen on normal reads or not... and this should > IMO be independent of whether the fs was mounted ro or rw. If you allow any write to filesystem before resuming from hibernation you risk corrupted filesystem. I strongly believe that "ro" must be really read-only - having separate option to control it will require update of every tool that generates initramfs and even then you cannot avoid using older initramfs with newer kernel. > I'd say the default should go for data safety (i.e. repair as soon as > possible). > Safety means exactly opposite for me - do not modify data if explicitly requested not to do it. Having filesystem in half-read-only state will be too error prone.