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. > As I don't see a way to gracefully solve this except keeping > drop_extents(), lets drop this patch instead. Understood. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
