On Tue, Sep 25, 2012 at 01:02:39PM -0400, Josef Bacik wrote: > > implemented as follows on top of next/master, in short: > > * disable overcommit completely > > * do the optimistically best guess for the metadata and reserve only up > > to the current tree height > > So I had tried to do this before, the problem is when height changes our > reserve > changes. So for things like delalloc we say we have X number of extents and > we > reserve that much space, but then when we run delalloc we re-calculate the > metadata size for X number extents we've removed and that number could come > out > differently since the height of the tree would have changed.
Understood, I did not came accross this during testing because I did not reproduce the required conditions that do not seem frequent but definetelly are possible. Let me proceed with V2: * disable overcommit completely * reserve only up to the current tree height + 1 You can object that the tree height may grow by 2, namely at the early stage from 0 -> 2 if the number of operations is quite high and all of this finishes within one transaction. So improvement that also covers that: * reserve up to MIN( BTRFS_MAX_LEVEL, max(tree->height + 1, 3) ) with the assumption that growing three from 3->4 will take more operations that could fit into one transaction period even on a fast device. (More accurate analysis required, but this should give the idea). The estimated savings in metadata block reservations start at 3/8 (and decreases with the larger filesystem use). This estimate does not have the property of being 'almost exact' as the V1 proposal, so some sort of overcommit math should also take place. I leave this out for now. thanks, david -- 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
