On Thu, Apr 25, 2019 at 09:50:25PM +0800, Qu Wenruo wrote: > > > On 2019/4/25 下午9:25, Josef Bacik wrote: > [snip] > >>> > >>> What if the commit is reverted, if the problem is otherwise hard to fix? > >>> This seems to break the semantics of fallocate so the performance should > >>> not the main concern here. > >> > > > > Are we sure the ENOSPC is coming from the data reservation? That change > > makes > > us fall back on the old behavior, which means we should still succeed at > > making > > the data reservation. > > > > However it fallocate() _does not_ guarantee you won't fail the metadata > > reservation, I suspect that may be what you are running into. > > For this script, we only needs 4 file extents at most. > Even the initial 8M metadata should be pretty enough, thus I don't think > it's metadata causing the problem. > --- > #!/bin/bash > > dev=/dev/test/test > mnt=/mnt/btrfs > > mkfs.btrfs -f $dev -b 512M > > mount $dev $mnt > > fallocate -l 384M $mnt/file1 > echo "fallocate success" > sync > dd if=/dev/zero bs=512K oflag=direct conv=notrunc count=768 of=$mnt/file2 >
Wellll we don't do the nocow check _at all_ for O_DIRECT, so mystery solved there. Josef
