On Thu, Aug 30, 2012 at 09:18:07AM -0600, Mitch Harder wrote: > I've been trying out different leafsize/nodesize settings by > benchmarking some typical operations. > > These changes had more impact than I expected. Using a > leafsize/nodesize of either 8192 or 16384 provided a noticeable > improvement in my limited testing. > > These results are similar to some that Chris Mason has already > reported: https://oss.oracle.com/~mason/blocksizes/ > > I noticed that metadata allocation was more efficient with bigger > block sizes. My data was git kernel sources, which will utilize > btrfs' inlining. This may have tilted the scales. > > Read operations seemed to benefit the most. Write operations seemed > to get punished when the leafsize/nodesize was increased to 64K. > > Are there any known downsides to using a leafsize/nodesize bigger than > the default 4096? >
Once you cross some hardware dependant threshold (usually past 32k) you start incurring high memmove() overhead in most workloads. Like all benchmarking its good to test your workload and see what works best, but 16k should generally be the best option. Thanks, Josef -- 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
