On Thu, Apr 25, 2019 at 10:11:41PM +0800, Qu Wenruo wrote: > > > On 2019/4/25 下午10:09, Josef Bacik wrote: > > 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. > > Oh, wrong flag, remove that oflag and we still get the same problem. > > fallocate success > dd: error writing '/mnt/btrfs/file2': No space left on device > 95+0 records in > 94+0 records out > 49283072 bytes (49 MB, 47 MiB) copied, 0.0807034 s, 611 MB/s >
Hmph, then I'm not sure, and I've already exceeded my allowed btrfs/things I enjoy time for this month. If we really are getting enospc from the data reservation then it must mean that the nocow check is failing when it shouldn't. It shouldn't be hard for you to narrow down what's going wrong. Thanks, Josef
