From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:48685 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750954AbaIBUKV (ORCPT ); Tue, 2 Sep 2014 16:10:21 -0400 Message-ID: <54062424.9040508@fb.com> Date: Tue, 2 Sep 2014 16:10:12 -0400 From: Chris Mason MIME-Version: 1.0 To: john terragon , Duncan <1i5t5.duncan@cox.net> CC: Subject: Re: kernel 3.17-rc3: task rsync:2524 blocked for more than 120 seconds References: <540498AF.6030109@fb.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Sender: linux-btrfs-owner@vger.kernel.org List-ID: > On 09/02/2014 03:56 PM, john terragon wrote: > Nice...now I get the hung task even with 3.14.17.... And I tried with > 4K for node and leaf size...same result. And to top it all off, today > I've been bitten by the bug also on my main root fs (which is on two > fast ssd), although with 3.16.1. > > Is it at least safe for the data? I mean, as long as the hung process > terminates and no other error shows up, can I at least be sure that > the data written is correct? Your traces are a little different. The ENOSPC code is throttling things to make sure you have enough room for the writes you're doing. The code we have in 3.17-rc3 (or my for-linus branch) are the best choices right now. You can pull that down to 3.16 if you want all the fixes on a more stable kernel. Nailing down the ENOSPC code is going to be a little different, I think autodefrag probably isn't interacting well with being short on space and encryption. This is leading to much more IO than we'd normally do, and dm-crypt makes it fairly intensive. Can you try flipping off autodefrag? -chris