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 Thanks, Qu > > Josef >
signature.asc
Description: OpenPGP digital signature
