From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f181.google.com ([74.125.82.181]:53052 "EHLO mail-ot0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbdKHRRa (ORCPT ); Wed, 8 Nov 2017 12:17:30 -0500 Received: by mail-ot0-f181.google.com with SMTP id 18so2908530oty.9 for ; Wed, 08 Nov 2017 09:17:30 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <9871a669-141b-ac64-9da6-9050bcad7640@cn.fujitsu.com> <2164b4b2-1447-3670-73ae-465404754b87@gmail.com> From: Chris Murphy Date: Wed, 8 Nov 2017 10:17:28 -0700 Message-ID: Subject: Re: Problem with file system To: "Austin S. Hemmelgarn" Cc: Chris Murphy , Dave , Linux fs Btrfs Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Wed, Nov 8, 2017 at 5:13 AM, Austin S. Hemmelgarn wrote: >> It definitely does fix ups during normal operations. During reads, if >> there's a UNC or there's corruption detected, Btrfs gets the good >> copy, and does a (I think it's an overwrite, not COW) fixup. Fixups >> don't just happen with scrubbing. Even raid56 supports these kinds of >> passive fixups back to disk. > > I could have sworn it didn't rewrite the data on-disk during normal usage. > I mean, I know for certain that it will return the correct data to userspace > if at all possible, but I was under the impression it will just log the > error during normal operation. No, everything except raid56 has had it since a long time, I can't even think how far back, maybe even before 3.0. Whereas raid56 got it in 4.12. -- Chris Murphy