From patchwork Thu Aug 14 22:03:09 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Mason X-Patchwork-Id: 4725621 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id DA004C0338 for ; Thu, 14 Aug 2014 22:03:34 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 05DD3201B9 for ; Thu, 14 Aug 2014 22:03:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2A4C72017E for ; Thu, 14 Aug 2014 22:03:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754808AbaHNWD3 (ORCPT ); Thu, 14 Aug 2014 18:03:29 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:63793 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754424AbaHNWD2 (ORCPT ); Thu, 14 Aug 2014 18:03:28 -0400 Received: from pps.filterd (m0004348 [127.0.0.1]) by m0004348.ppops.net (8.14.5/8.14.5) with SMTP id s7ELj1F1011551; Thu, 14 Aug 2014 15:03:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=facebook; bh=wmUh5vUiyNjt0rjwdaF958Iu0bGwhrZfDEyq+dFPA18=; b=hioJIyyEJsRlzt7taHDM0WGeGyo1yHacrfxt7z2fsXbX5A/NvpOXgitokffAJT28IQOD 1VQ60ZRuXqIVmjxq0PW2S7kZhG5ZhlBA5okeZOts/lnqsGD7msNk4k/yXKgfdWGR+LZJ lLXTCEvZwg8Z3PIxl0VEath3V/Y0sDwQMEU= Received: from mail.thefacebook.com (mailwest.thefacebook.com [173.252.71.148]) by m0004348.ppops.net with ESMTP id 1ns1aj0m59-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 14 Aug 2014 15:03:13 -0700 Received: from [172.23.2.80] (192.168.57.29) by mail.thefacebook.com (192.168.16.16) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 14 Aug 2014 15:03:12 -0700 Message-ID: <53ED321D.1040702@fb.com> Date: Thu, 14 Aug 2014 18:03:09 -0400 From: Chris Mason User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marc MERLIN , Austin S Hemmelgarn CC: , , Subject: Re: btrfs-zero-log fails, can't mount FS References: <20140814160902.GA25370@merlins.org> <53ECE953.70009@gmail.com> <20140814172743.GC27531@merlins.org> In-Reply-To: <20140814172743.GC27531@merlins.org> X-Originating-IP: [192.168.57.29] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-14_05:2014-08-14, 2014-08-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 kscore.is_bulkscore=7.09835523693414e-11 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.324642340081358 urlsuspect_oldscore=0.324642340081358 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=2524143 rbsscore=0.324642340081358 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408140253 X-FB-Internal: deliver Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 08/14/2014 01:27 PM, Marc MERLIN wrote: > On Thu, Aug 14, 2014 at 12:52:35PM -0400, Austin S Hemmelgarn wrote: >> I don't think it is likely that the Samsung SSD is to blame, in my >> experience Samsung's SSD's are better than almost every other brand >> except Intel, and I know that they honor write-barriers correctly. >> The likely issue is that the system hung during the process of a commit, >> which is one of the few things that I know of that consistently corrupts >> the filesystem. There isn't really anything I know of to prevent it, >> except for making your system as stable as possible. >> Interestingly, this type of thing is the only issue I've ever had with >> BTRFS that wasn't traceable to hardware problems. > > That was my understanding too, thanks for confirming. > > Until this bug gets fixed, I'm perplexed as to why btrfs-zero-log isn't > fixing this. > Can't I unroll the last commits until I get to a stable one? > > As luck would have it (again), I'm boarding a plane to Chicago tomorrow to > go speak at linuxcon about btrfs. > I would very much like not to have to spend 12H to restore my SSD from > backup :) At least I'll get to buy you a beer this time. Lets just see if the log root is the only problem. This will get you through btrfs-zero-log --- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/disk-io.c b/disk-io.c index 8db0335..d9a8e19 100644 --- a/disk-io.c +++ b/disk-io.c @@ -911,13 +911,13 @@ int btrfs_setup_all_roots(struct btrfs_fs_info *fs_info, u64 root_tree_bytenr, return -EIO; } fs_info->csum_root->track_dirty = 1; - +#if 0 ret = find_and_setup_log_root(root, fs_info, sb); if (ret) { printk("Couldn't setup log root tree\n"); return -EIO; } - +#endif fs_info->generation = generation; fs_info->last_trans_committed = generation; if (extent_buffer_uptodate(fs_info->extent_root->node) &&