On 1/2/20 6:27 AM, Qu Wenruo wrote:
Although btrfs_calc_avail_data_space() is trying to do an estimation on how many data chunks it can allocate, the estimation is far from perfect: - Metadata over-commit is not considered at all - Chunk allocation doesn't take RAID5/6 into consideration Although current per-profile available space itself is not able to handle metadata over-commit itself, the virtual chunk infrastructure can be re-used to address above problems. This patch will change btrfs_calc_avail_data_space() to do the following things: - Do metadata virtual chunk allocation first This is to address the over-commit behavior. If current metadata chunks have enough free space, we can completely skip this step. - Allocate data virtual chunks as many as possible Just like what we did in per-profile available space estimation. Here we only need to calculate one profile, since statfs() call is a relative cold path. Now statfs() should be able to report near perfect estimation on available data space, and can handle RAID5/6 better. Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
Can you put a comparison of the statfs call time for the old way vs the new way in your changelog? Say make a raid5 fs for example, populate it a little bit, and then run statfs 10 times and take the average with and without your patch so we can make sure there's no performance penalty. You'd be surprised how many times statfs() things have caused problems for us in production. Thanks,
Josef
