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 180C1138CCF for ; Tue, 5 May 2015 12:53:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6C2ABE086E; Tue, 5 May 2015 12:53:35 +0000 (UTC) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) (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 758BBE085E for ; Tue, 5 May 2015 12:53:34 +0000 (UTC) Received: by obblk2 with SMTP id lk2so99167545obb.0 for ; Tue, 05 May 2015 05:53:33 -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=7IIq4gUpfuDv87A/52L63vHZAVmQMaMdm9k2MWDsuaA=; b=Dg5623RnqbWOWmULILwIQYGVvLtLsmUOZZBMLM+QCRkmu4iSczyvcumxq5IFjp/FSa +V7OM2ADISO2w4EB5Bv4XKcW8D24zpmWyLqlXLsxR6d/mAH3VlMAwggymGohhJC/yDzV xIt/Mewvc65obfmxkWuHrch77ckYJfyU6h0vWgVECKin4jvzK3L9270Ld8FfPhReMP+V 27tHRALNEzRqbNEoyQGoll/gCE7uwrPBGVuR74DBLdt3dDCEJyYgyhjrG1DoH8DkcqQ5 ICsJSojNxKL9v/Ey0TFpN+SuMZl6KGGjSTaUFor6qMtnr7ZFpXnuTAUmQb99Y24EfQ+7 ho5w== 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.98.73 with SMTP id eg9mr1546808igb.10.1430830409353; Tue, 05 May 2015 05:53:29 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.107.48.66 with HTTP; Tue, 5 May 2015 05:53:29 -0700 (PDT) In-Reply-To: <20150505132147.744e4f2d@digimed.co.uk> References: <553F474E.4040101@gmail.com> <20150505123338.5a8d4ad3@digimed.co.uk> <201505051306.15821.michaelkintzios@gmail.com> <20150505132147.744e4f2d@digimed.co.uk> Date: Tue, 5 May 2015 08:53:29 -0400 X-Google-Sender-Auth: lKXN1DGuTHTQ148JrRQ5LeKSRV0 Message-ID: Subject: Re: [gentoo-user] Hard drive storage questions From: Rich Freeman To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: cfb8b7cf-8aee-4b32-951b-6332e44e24e4 X-Archives-Hash: 8df9e287b9604c7751e319510a0b7944 On Tue, May 5, 2015 at 8:21 AM, Neil Bothwick wrote: > On Tue, 5 May 2015 13:05:55 +0100, Mick wrote: > >> During a backup of a home directory I noticed loads of Chromium and >> Firefox crash/recovery files being copied over. However, I don't know >> if this is a btrfs problem, or the fact that I had to forcefully shut >> down KDE once or twice recently, because the desktop would not >> logout/shutdown normally. > > Chromium saves its open tabs and reopens them after a reboot, even if it > is shut down forcibly. > >> The fsck which ran when the machine rebooted did not revealed any >> problems. Is there a different recommended way for checking for fs >> errors? > > btrfs check - it needs the filesystem to be unmounted and has a repair > option. I don't think the chromium/firefox issues are in any way a sign of a filesystem problem. Application crashing and filesystem errors are completely different matters. If atop dumps core 14 times a day (as it seems to love to do) btrfs just happily stores them in case I ever want to look at them. In general btrfs tends to do most of its fixing online. I'd only run btrfs check if the filesystem is unmountable. I wouldn't trust it not to do more harm than good. For a very long time it didn't even exist, and btrfs is a bit different from most other filesystems in this regard. btrfs doesn't complain if you mount it unclean - almost all the recovery code is in the kernel and it will generally tidy up as it goes. This is in contrast to many other filesystems that force you to run fsck if they were not cleanly unmounted. I'm not saying it is broken. I haven't really used it much. However, for the most part btrfs was designed around doing most of its operations online and these are probably the more mature code paths. That said, btrfs check without the --repair option should be read-only, so you can always try it. However, I wouldn't be surprised at all if there are no problems with your filesystem (assuming you run it after a clean shutdown). If there were any problems, btrfs should have cleaned them up on your last mount. btrfs does not overwrite data in-place in any case, so it is a bit like ext4 with data=journal in normal operation. And that is what I like about btrfs (and the same applies to zfs) - the basic design of the filesystem tends to prioritize data integrity, and thus even with all my panics and mounting problems with btrfs, I've always been able to recover, and at every point I could at least mount the filesystems read-only and read everything off of them. And a successful read on btrfs/zfs means that the checksum matched, so the risk of corruption is fairly low. -- Rich