Re: [PATCH] Btrfs: do not abort transaction when failing to insert hole extent

[Liu Bo <obuil.liubo@gmail.com>]

On Tue, Apr 10, 2018 at 5:12 AM, David Sterba <dsterba@suse.cz> wrote:
> On Mon, Apr 09, 2018 at 06:23:14PM -0700, Liu Bo wrote:
>> >>> As maybe_insert_hole is only called by btrfs_cont_expand here, which
>> >>> means it's a really hole, I don't expect drop_extents would drop
>> >>> anything, we can remove this drop_extents and put an assert after
>> >>> btrfs_insert_file_extent for checking EEXIST.
>> >> Sounds good.
>> > Let me make a v2 and have a fstests run.
>> It turns out that the btrfs_drop_extents() here is quite necessary
>> since fallocate(2) has a FALLOC_FL_KEEP_SIZE option, and when that
>> happens, a hole extent would be appended between the EOF and fallocate
>> range's start, then a later truncate up would have to drop these hole
>> extents in order to expand with a new hole...
>
> Would it make sense to split the cases where FALLOC_FL_KEEP_SIZE is and
> is not used? Either passing an argument or 2 functions where one could
> avoid the drop. I've looked at the code only briefly, so this may be a
> nonsense in the end.
>

I'm afraid that It won't work as there is no way I could think of to
know whether an inode has been fallocate with KEEP_SIZE, IOW, seems
that we have to do a search to check if there are extra extents beyond
EOF.

thanks,
liubo

>> As I don't see a way to gracefully solve this except keeping
>> drop_extents(), lets drop this patch instead.
>
> Understood.