From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81ECBC35249 for ; Sun, 2 Feb 2020 19:56:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 243B3206D3 for ; Sun, 2 Feb 2020 19:56:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=colorremedies-com.20150623.gappssmtp.com header.i=@colorremedies-com.20150623.gappssmtp.com header.b="okMtlRdP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726921AbgBBT4w (ORCPT ); Sun, 2 Feb 2020 14:56:52 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:38262 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726290AbgBBT4w (ORCPT ); Sun, 2 Feb 2020 14:56:52 -0500 Received: by mail-wr1-f65.google.com with SMTP id y17so15306908wrh.5 for ; Sun, 02 Feb 2020 11:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorremedies-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GGPHZrmfqckR3+PehfRD5MALpm96/TC+7LXgyyq/zmA=; b=okMtlRdPiVoosSI1nxstVDTtDOsp2rtIRINiKDZYmSMkBM9pisctdIxl3L7TDMH+k4 oBXmsNJ+tV01mhFHghMsbOeCyJCmIRJ8cfFgvPAOOgF8XSJ3UAS+ZnH7PcGQHbIrrC9B nhvWRqj+eAgW4GlF8k597Ypf9F3RbXpQ72PtpJoqmWYG5cafdr3wd8Ao60V0rwJSYSTi 3PCqA5qZcl7WamNF3w+xPsEdg/1qZK+601FaNMOrtC4qKj+MDMheX0N3oSWekz10OoGc JkYeT0f1sVBVhrxXsbYd52vVDIrKJFbGAjnUQ54gwTdXIR1YVAk3n9AjaSrCPQK3LfJd JPMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GGPHZrmfqckR3+PehfRD5MALpm96/TC+7LXgyyq/zmA=; b=UZwBt+dEgIlbB9DbCgpwrOD8BbBqfNKaVtFseySPdVEDueEXtbx2sORJ5PpgBbUcE0 1Da0Mb5VN7t1NFGf28LElUIjphlrRHmcflegN4Jx1QuNjp/ICMclPuWMfATbgzXRXEdb zlQQqHrtoIIMOnAoTblQfz8WyK6SQYCXREobU0j/U++1GPpnhELrKy6DQ5TvENiUhISa yRCH5MZLfRCIvMvJbeMhq7XPW4h6hM+bTpVO2HXPF3CBXet4jhmdear8Qe6oQkZWxt0n zXgyrESm74QnQOvllIytUVxauyyXExjrFpWG6UbyuHLOOOcv93M6AfeJ5BCZ9wK9T6bX b4jw== X-Gm-Message-State: APjAAAVWEQXdc+pL+Fn+rxNFillZuNeLWeerlEJdABinog9UL86FuaGY rQ2/QMrA/oC2pN15XJpnkinYloFZiwKAiKrIrg5QO4KRaXM= X-Google-Smtp-Source: APXvYqwGuGfRanHTFtlcNZw+1VPPowEs97YcHowXfzjXpR8v249MwqpTQXgSkvG9pUSe6bDDVUwxxokZHTC6c5H7L0w= X-Received: by 2002:adf:ab14:: with SMTP id q20mr11087336wrc.274.1580673409932; Sun, 02 Feb 2020 11:56:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Chris Murphy Date: Sun, 2 Feb 2020 12:56:34 -0700 Message-ID: Subject: Re: My first attempt to use btrfs failed miserably To: Skibbi Cc: Btrfs BTRFS Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Sun, Feb 2, 2020 at 5:45 AM Skibbi wrote: > root@rpi4b:~# dmesg |grep btrfs > [223167.290255] BTRFS: error (device dm-0) in > btrfs_run_delayed_refs:2935: errno=-5 IO failure > [223167.389690] BTRFS: error (device dm-0) in > btrfs_run_delayed_refs:2935: errno=-5 IO failure > root@rpi4b:~# dmesg |grep BTRFS The entire unfiltered dmesg is needed. This older kernel doesn't have new enough Btrfs tree checker code to help determine what the problem is. > [203285.351377] BTRFS error (device sda1): bad tree block start, want > 31457280 have 0 > [203285.466743] BTRFS info (device sda1): read error corrected: ino 0 > off 32735232 (dev /dev/sda1 sector 80320) > [218811.383208] BTRFS error (device dm-0): bad tree block start, want > 50659328 have 7653333615399691647 These happening together suggest lower storage stack failure. Since kernel messages are filtered it only shows that Btrfs is working as designed, complaining about known bad file system metadata. But because it's filtered, it's not clear why the metadata has gone bad. > [223167.290255] BTRFS: error (device dm-0) in > btrfs_run_delayed_refs:2935: errno=-5 IO failure More suggestion of IO failure, whether physical device or logical layer in between Btrfs and physical device. Btrfs trusts the storage stack *less* than other file systems, by design. It's a kind of canary in the coal mine. Other file systems assume the storage stack is working, so they're less likely to complain. Only recent versions of e2fsprogs will format ext4 using metadata checksumming enabled. The kind of problems you're reporting look so bad and happen so fast I'd expect a good chance you'd reproduce the same problem with any metadata checksumming file system, if you have new enough progs to enable them. -- Chris Murphy