On Wed, Jun 17, 2020 at 01:37:59PM +0200, David Sterba wrote: > On Wed, Jun 03, 2020 at 08:55:00AM +0300, Nikolay Borisov wrote: > > V2 with purely cosmetic changes in the line length of some patches' changelogs. > > > > For the cover letter of substance for this series check v1 [0] cover letter. > > > > [0] https://lore.kernel.org/linux-btrfs/SN4PR0401MB3598824C8AE02453F8ABD61A9B8B0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/T/#t > > > > Nikolay Borisov (46): > > btrfs: Make __btrfs_add_ordered_extent take struct btrfs_inode > > btrfs: Make get_extent_allocation_hint take btrfs_inode > > btrfs: Make btrfs_lookup_ordered_extent take btrfs_inode > > btrfs: Make btrfs_reloc_clone_csums take btrfs_inode > > btrfs: Make create_io_em take btrfs_inode > > btrfs: Make extent_clear_unlock_delalloc take btrfs_inode > > btrfs: Make btrfs_csum_one_bio takae btrfs_inode > > btrfs: Make __btrfs_drop_extents take btrfs_inode > > I've applied 1-8 to misc-next, that's what applied cleanly when I first > looked at the series and still applies now, with a minor conflict and > manual fix to recently added "btrfs: fix RWF_NOWAIT writes blocking on > extent locks and waiting for IO". > > 46 in one go seem to be too much, I'll try to apply the rest in case the > fixups won't get out of hand. Still a lot of fixups, I'll keep it in a topic branch in for-next to reduce conflict surface but will push it to misc-next at rc3 time. The transition to btrfs_inode is worth, but please let's do it in smaller batches next time, 20 patches should be ok. The turnaround time should be shorter as the expected number of post-merge window fixes is now going to be low. Thanks.
