> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
