On Thu, Sep 20, 2012 at 2:03 PM, Josef Bacik <jba...@fusionio.com> wrote: > Hello, > > I'm going to look at fixing some of the performance issues that crop up > because > of our reservation system. Before I go and do a whole lot of work I want some > feedback.
When I was trying to figure out the problem with gzip ENOSPC issues, I spent some time debugging and following the flow through the reserve_metadata_bytes() function in extent-tree.c. My observation was that the accounting around space_info->bytes_may_use did not appear to be tightly closed. The space_info->bytes_may_use value would grow large (often 3 or 4 times greater than space_info->total), and the flow through reserve_metadata_bytes() would stay in overcommit. I was unsuccessfull in figuring out how to rework or close the loop on the accounting for space_info->bytes_may_use. I noticed that btrfs seemed to work OK even though the value in space_info->bytes_may_use appeared inexplicably large, and btrfs was always in overcommit. So, since you're asking for possibly 'crazy ideas', I suggest considering finding a way to ignore space_info->bytes_may_use in reserve_metadata_bytes(). Either make the overcommit the default (which I found to approximate my real-life case anyhow), or have a simple mechanism for quick fail-over to overcommit. I doubt this will be any kind of comprehensive fix for ENOSPC issues, but simplifying reserve_metadata_bytes() may make it easier to find the other issues. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
