On 2019/4/25 下午10:13, Josef Bacik wrote: > 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,
Yep, no need to bother, I'll pin down the problem. And thanks again for your idea on the bytes_may_use fix. Thanks, Qu > > Josef >
signature.asc
Description: OpenPGP digital signature
