| Message ID | 20231213-btrfs_map_block-cleanup-v2-0-cf5cfb9e2400@wdc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | btrfs: clean up RAID I/O geometry calculation | expand |
On Wed, Dec 13, 2023 at 06:42:55AM -0800, Johannes Thumshirn wrote: > The calculation of the RAID I/O geometry in btrfs_map_block has been a maze of > if-else statements for a very long time and the advent of the > raid-stripe-tree made the situation even worse. > > This patchset refactors btrfs_map_block() to untagle the maze and make I/O > geometry setting easier to follow, but does not introduce any functional > changes. > > I've also run it through Josef's CI and there have been test failures, but > none of them introduced by these patches. > > --- > Changes in v2: > - add btrfs_map_op into struct btrfs_io_geometry > - split RAID56 read and write into two different helpers > - drop redundand 'for' in helper function names > - kept dev_replace_is_ongoing variable name > - Link to v1: https://lore.kernel.org/r/20231212-btrfs_map_block-cleanup-v1-0-b2d954d9a55b@wdc.com > > --- > Johannes Thumshirn (13): > btrfs: factor out helper for single device IO check > btrfs: re-introduce struct btrfs_io_geometry > btrfs: factor out block-mapping for RAID0 > btrfs: factor out RAID1 block mapping > btrfs: factor out block mapping for DUP profiles > btrfs: factor out block mapping for RAID10 > btrfs: reduce scope of data_stripes in btrfs_map_block > btrfs: factor out block mapping for RAID5/6 > btrfs: factor out block mapping for single profiles > btrfs: btrfs: untagle if else maze in btrfs_map_block > btrfs: open code set_io_stripe for RAID56 > btrfs: pass struct btrfs_io_geometry to set_io_stripe > btrfs: pass btrfs_io_geometry into btrfs_max_io_len Added to misc-next with some adjustments, thanks. I've noticed some of the helpers can take const parameters, some lines that can be joined so the expression is one one line, but there are calculations like in "btrfs: open code set_io_stripe for RAID56" where it's up to your creativity.
The calculation of the RAID I/O geometry in btrfs_map_block has been a maze of if-else statements for a very long time and the advent of the raid-stripe-tree made the situation even worse. This patchset refactors btrfs_map_block() to untagle the maze and make I/O geometry setting easier to follow, but does not introduce any functional changes. I've also run it through Josef's CI and there have been test failures, but none of them introduced by these patches. --- Changes in v2: - add btrfs_map_op into struct btrfs_io_geometry - split RAID56 read and write into two different helpers - drop redundand 'for' in helper function names - kept dev_replace_is_ongoing variable name - Link to v1: https://lore.kernel.org/r/20231212-btrfs_map_block-cleanup-v1-0-b2d954d9a55b@wdc.com --- Johannes Thumshirn (13): btrfs: factor out helper for single device IO check btrfs: re-introduce struct btrfs_io_geometry btrfs: factor out block-mapping for RAID0 btrfs: factor out RAID1 block mapping btrfs: factor out block mapping for DUP profiles btrfs: factor out block mapping for RAID10 btrfs: reduce scope of data_stripes in btrfs_map_block btrfs: factor out block mapping for RAID5/6 btrfs: factor out block mapping for single profiles btrfs: btrfs: untagle if else maze in btrfs_map_block btrfs: open code set_io_stripe for RAID56 btrfs: pass struct btrfs_io_geometry to set_io_stripe btrfs: pass btrfs_io_geometry into btrfs_max_io_len fs/btrfs/volumes.c | 410 +++++++++++++++++++++++++++++++++-------------------- 1 file changed, 259 insertions(+), 151 deletions(-) --- base-commit: 14d1d39586246ca9d4ce97049c98be849e3bbcd9 change-id: 20231207-btrfs_map_block-cleanup-346f53aff90d Best regards,