On Tue, Apr 10, 2018 at 5:12 AM, David Sterba <dsterba@xxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
