From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id BAA59139B2A for ; Fri, 18 Sep 2015 18:30:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9CB4C21C0B9; Fri, 18 Sep 2015 18:30:51 +0000 (UTC) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 974F9E08E1 for ; Fri, 18 Sep 2015 18:30:50 +0000 (UTC) Received: by igbkq10 with SMTP id kq10so41885492igb.0 for ; Fri, 18 Sep 2015 11:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=o6AuA+Fo71ybk3rQl5mFK23XDP84+bH28tl20BCzWLw=; b=Q1iEENTlyM3hxrO/4dRolIlm8CuGI2ykPDXWp/fIbeR80XavHj0H17xom/kEXabsAQ ePa/ExRIPhSgHYbOwjry4azP2x9Oo0ZDWq2YonNMy5eBz1eJ9gea/Wnem4EwcY2PGiSp pi/7vqdG7Lw28nUYfhGCHQfdODHqc34uH3woScoet+VMyRq3mCS8BBVOrB0KbTpFcB7i 5VJr5UcyJI9KBHGYrPmTYGXD7BzhLeistziy7K2lkJlLsX3FcF3gSQzQ9tF0uEKbwydY aliant7D6zV3JMaFHj/Y0jnI0UnvTprOSydlHcIWsQ4axxdSiIlDlnxfVr0eaflcRwuU v57Q== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.29.101 with SMTP id j5mr33830415igh.70.1442601049840; Fri, 18 Sep 2015 11:30:49 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.79.103.70 with HTTP; Fri, 18 Sep 2015 11:30:49 -0700 (PDT) In-Reply-To: <201509181920.08912.michaelkintzios@gmail.com> References: <201509162222.40567.michaelkintzios@gmail.com> <201509181857.00834.michaelkintzios@gmail.com> <201509181920.08912.michaelkintzios@gmail.com> Date: Fri, 18 Sep 2015 14:30:49 -0400 X-Google-Sender-Auth: AXzwQhg_iixFcpQ5Zx4KJTIj_SY Message-ID: Subject: Re: [gentoo-user] BTRFS problem? [WAS Quick check on net-print/hplip-3.14.10] From: Rich Freeman To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 7b38c608-4dcb-4354-af5c-da0d92ee2484 X-Archives-Hash: 31c3f456904a8bd92211a69c311a4a64 On Fri, Sep 18, 2015 at 2:19 PM, Mick wrote: > On Friday 18 Sep 2015 19:15:50 Rich Freeman wrote: >> On Fri, Sep 18, 2015 at 1:56 PM, Mick wrote: >> > On Friday 18 Sep 2015 17:16:54 Marc Joliet wrote: >> >> On Friday 18 September 2015 10:31:01 Mick wrote: >> >> >A couple of months ago the akonadi DB went sideways and kmail played up >> >> >as a result. Again I was suspicious of btrfs, but neither the logs >> >> >nor fsck showed up anything. >> >> >> >> I take it "btrfs scrub" didn't turn up anything, or is that what you >> >> meant by fsck? >> > >> > Am I supposed to run scrub with I do not have a RAID running? I thought >> > scrub was meant for comparing checksums between mirrored fs - have I got >> > this wrong? >> >> You can actually run scrub on a non-raid btrfs setup. Btrfs will >> report any errors that it detects (using the checksumming in the >> filesystem), but it would not be able to fix errors unless you have it >> storing redundant data somewhere (even on non-raid it still stores >> redundant metadata by default, and you can choose to do this with data >> as well which protects against block-level failures but not disk-level >> failures, obviously). >> >> However, you'd have gotten the same errors in dmesg just trying to >> read the files - btrfs checks the checksum on all file read >> operations. That is a big part of the value of both btrfs and zfs. > > Ah! V interesting ... can I run scrub with mounted partitions, or do I have > to do it from a LiveCD? I didn't check, but I suspect you can only run scrub on a mounted partition. I also suspect that fsck probably has an option to do something equivalent offline. You do get the error-detection anyway just by reading files, and if you just ran find on your filesystem and catted every file you have to /dev/null that would actually accomplish the same thing as long as you're not in a redundant mode (simply reading all the files doesn't guarantee that all copies of each file are checked). The main reason for doing a scrub is to detect latent issues, and if you have redundancy that means you can auto-correct them today, rather than discovering them a month from now when the drive containing the only good copy fails. Even if you don't have redundancy maybe you rotate your backups every 30 days and detecting the error might mean having the ability to go back and restore a good copy of the file before it is completely replaced with bad copies. -- Rich