From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f41.google.com ([209.85.218.41]:52273 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751437AbdJ2TFQ (ORCPT ); Sun, 29 Oct 2017 15:05:16 -0400 Received: by mail-oi0-f41.google.com with SMTP id c202so18069095oih.9 for ; Sun, 29 Oct 2017 12:05:16 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1484297967.48018.1508985286675@email.1and1.com> References: <1484297967.48018.1508985286675@email.1and1.com> From: Chris Murphy Date: Sun, 29 Oct 2017 20:05:15 +0100 Message-ID: Subject: Re: btrfs send yields "ERROR: send ioctl failed with -5: Input/output error" To: Zak Kohler Cc: "Lakshmipathi.G" , btrfs Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Thu, Oct 26, 2017 at 4:34 AM, Zak Kohler wrote: > I will gladly repeat this process, but I am very concerned why this > corruption happened in the first place. Right. So everyone who can, needs to run the three scrubs on all available Btrfs volumes/devices and see if they get any discrepancies. I only ever use the online scrub so I have no idea if --offline or the older check --check-data-csum differ from it. scrub start scrub start --offline btrfs check --check-data-csum I think you've hit a software bug if those three methods don't exactly agree with each other. And it's a question which one is correct, or if they all have different bugs in them? > > More tests: > > scrub start --offline > All devices had errors in differing amounts > I will verify that these counts are repeatable. > Csum error: 150 > Csum error: 238 > Csum error: 175 > > btrfs check > found 2179745955840 bytes used, no error found > > btrfs check --check-data-csum > mirror 0 bytenr 13348855808 csum 2387937020 expected csum 562782116 > mirror 0 bytenr 23398821888 csum 3602081170 expected csum 1963854755 Offhand that sounds like three different results, which is sorta fakaked. > ... > > The only thing I could think of is that the btrfs version that I used to mkfs > was not up to date. Is there a way to determine which version was used to > create the filesystem? That information isn't in the superblock. I think it could be added to the device tree as a PERSISTENT_ITEM, although I'm not sure how useful it is. Anyway, I don't think it's related. mkfs.btrfs writes a tiny amount to the drive, and almost certainly the problem is happening later. -- Chris Murphy