From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (unknown [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C26F71381FA for ; Sat, 17 May 2014 00:08:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4A36EE0762; Sat, 17 May 2014 00:08:32 +0000 (UTC) Received: from icp-osb-irony-out8.external.iinet.net.au (icp-osb-irony-out8.external.iinet.net.au [203.59.1.225]) by pigeon.gentoo.org (Postfix) with ESMTP id C5693E09EC for ; Sat, 17 May 2014 00:08:30 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAHKndlNqRXN8/2dsb2JhbABZgwaqdgaXF4MTAYENFnSCJQEBBXgRCw0LCRYPCQMCAQIBRRMIAQEXiCXRcReFVYgPchaEKgSKEo9GhmopjAaDRDA X-IronPort-AV: E=Sophos;i="4.97,1070,1389715200"; d="scan'208";a="819676143" Received: from unknown (HELO moriah.localdomain) ([106.69.115.124]) by icp-osb-irony-out8.iinet.net.au with ESMTP; 17 May 2014 08:08:28 +0800 Received: from localhost (localhost [127.0.0.1]) by moriah.localdomain (Postfix) with ESMTP id D4B7B334A for ; Sat, 17 May 2014 08:08:27 +0800 (WST) X-Virus-Scanned: amavisd-new at lan.localdomain Received: from moriah.localdomain ([127.0.0.1]) by localhost (moriah.lan.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cK2v2sMGFbM for ; Sat, 17 May 2014 08:08:17 +0800 (WST) Received: from [192.168.44.3] (moriah [192.168.44.3]) by moriah.localdomain (Postfix) with ESMTP id A223115B33 for ; Sat, 17 May 2014 08:08:17 +0800 (WST) Message-ID: <5376A871.7010609@iinet.net.au> Date: Sat, 17 May 2014 08:08:17 +0800 From: William Kenworthy User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] experience thus far References: <20140506121832.678ae781@marcec> <20140516221558.19e69a5b@marcec> In-Reply-To: <20140516221558.19e69a5b@marcec> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: bfa97309-ecef-4105-bb69-67b67bcb4915 X-Archives-Hash: 46855bb02372abf073035f4c9fe258c5 On 17/05/14 04:15, Marc Joliet wrote: > So, a week has passed since my conversion to btrfs. > > So far there seem to have been no problems, my system has been running as if > nothing has changed :) . Which, as a friend pointed out, is how it should be. > > I don't think there is anything particularly interesting to mention in addition > to what I already wrote. I can just say that I think the effort was worth it. > > The one thing that I can tell from reading the past two weeks of the btrfs ML > is that the 3.15 Linux kernel series will contain lots of bug fixes (for > example in balancing, error handling, and send/receive), and that I will want > to use that sooner rather than later. Of course, the severity of the problems > varies, and a lot are triggered under odd, or at least uncommon, circumstances. > Still, its worth paying attention to. > > Also, a lot of problem reports I saw came from people using other volume > management below btrfs, interestingly enough. > > As for the future, I think I will wait a while, and get some experience with > btrfs first. I suspect that by the time btrfs supports swap files, it will be > stable enough that I would consider converting my SSD to also use btrfs > anyway :) . Possibly before that, once I am fully convinced of btrfs' > stability, I will also convert my backup drive and switch to using snapshots > and send/receive to perform backups. Perhaps somebody will have written a > backup solution on top of snapshots by then. > > Have a nice weekend, > Don't forget to have a maintenance program - run a scrub regularly once a week or so - I have enough btrfs drives (22 qemu files, 4 WD Greens att) to see about one or two scrub fixable errors a week with no obvious cause, sometimes serious (in a critical file). My experience is that if you ignore these errors they seem to increase over time resulting in a crash and burn. Keep an eye on your logs as btrfs will list the errors there as well ("grep -i btrfs /var/log/messages"). For the ones scrub cant fix, delete the file and restore from backup. Errors that require off-line fixing (btrfsck) are the ones where I have lost file systems - though I have not seen this in the last 6 months. I am quite practised in restoring from backups because of btrfs :) BillK