From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f44.google.com ([209.85.218.44]:36078 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752180AbcHKUn6 (ORCPT ); Thu, 11 Aug 2016 16:43:58 -0400 Received: by mail-oi0-f44.google.com with SMTP id f189so9965914oig.3 for ; Thu, 11 Aug 2016 13:43:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Chris Murphy Date: Thu, 11 Aug 2016 14:43:56 -0600 Message-ID: Subject: Re: checksum error in metadata node - best way to move root fs to new drive? To: Duncan <1i5t5.duncan@cox.net> Cc: Btrfs BTRFS Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Thu, Aug 11, 2016 at 1:07 PM, Duncan <1i5t5.duncan@cox.net> wrote: > The compression-related problem is this: Btrfs is considerably less > tolerant of checksum-related errors on btrfs-compressed data, Why? The data is the data. And why would it matter if it's application compressed data vs Btrfs compressed data? If there's an error, Btrfs is intolerant. I don't see how there's a checksum error that Btrfs tolerates. But also I don't know if the checksum is predicated on compressed data or uncompressed data - does the scrub blindly read compressed data, checksums it, and compares to the previously recorded csum? Or does the scrub read compressed data, decompresses it, checksums it, then compares? And does compression compress metadata? I don't think it does from some of the squashfs testing of the same set of binary files on ext4 vs btrfs uncompressed vs btrfs compressed. The difference is explained by inline data being compressed (which it is), so I don't think the fs itself gets compressed. Chris Murphy -- Chris Murphy