Re: fallocate does not prevent ENOSPC on write

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1584 bytes --]



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
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]