On 2019/4/25 下午10:43, Filipe Manana wrote: > On Thu, Apr 25, 2019 at 3:28 PM 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 > > I don't get it. Why is this unexpected error? > You created a fs with 512Mb, fallocated 384Mb for a file named file1, > and then tried to write 384Mb 512K * 768 to a file named file2 (i.e. a > different file). > Wasn't the test supposed to write to file1 instead? My brain wasn't working last night. :( It should write into file1, and it passes in that case. Thanks, Qu > >> 95+0 records in >> 94+0 records out >> 49283072 bytes (49 MB, 47 MiB) copied, 0.0807034 s, 611 MB/s >> >> Thanks, >> Qu >> >>> >>> Josef >>> >> > >