On Thu, Nov 21, 2013 at 09:43:18PM +0800, Miao Xie wrote: > Before applying this patch, the task had to reclaim the metadata space > by itself if the metadata space was not enough. And When the task started > the space reclamation, all the other tasks which wanted to reserve the > metadata space were blocked. At some cases, they would be blocked for > a long time, it made the performance fluctuate wildly. > So the reason the flushing is done this way is because of this level of hell called "early enospc." Basically we'd get people flushing randomly and other users would come in and use the reclaimed space, so whoever was flushing would often ENOSPC because they thought they did everything they could to flush and still couldn't make allocations. This approach is a nice balance keeping the old "one at a time" flushers and adding a background flusher, but I still worry about people competing with the background flushing. Consider the case where the background flusher has started and taken all of the ordered extents on the system to flush (and lets assume that we only have reservations tied up in ordered extents, which is very possible). Then a task comes in to make a reservation but it can't because it doesn't have space, so it tries to flush. But the inline flushing stuff doesn't find any ordered extents to flush because they've been spliced off the list by the background flusher. So we bail out and do -ENOSPC even though there is plenty of space. What I would like to see is some way for a flusher who has to flush inline be able to see that there is a background flusher and wait for it to finish its work before doing its own flushing. If I have to start tracking down early ENOSPC problems again I may very well quit doing file system work forever. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
