Re: [PATCH v3 03/11] btrfs: introduce new members for extent_map

[David Sterba <dsterba@suse.cz>]

On Fri, May 24, 2024 at 08:49:25AM +0930, Qu Wenruo wrote:
> 
> 
> 在 2024/5/24 02:23, Filipe Manana 写道:
> [...]
> >> @@ -832,10 +897,11 @@ void btrfs_drop_extent_map_range(struct btrfs_inode *inode, u64 start, u64 end,
> >>                                          split->orig_start = em->orig_start;
> >>                                  }
> >>                          } else {
> >> +                               split->disk_num_bytes = 0;
> >> +                               split->offset = 0;
> >>                                  split->ram_bytes = split->len;
> >>                                  split->orig_start = split->start;
> >>                                  split->block_len = 0;
> >> -                               split->disk_num_bytes = 0;
> >
> > Why move the assignment of ->disk_num_bytes ?
> > This is sort of distracting, doing unnecessary changes.
> 
> It's to group the newer members together, and to follow the new trend to
> put them in disk_bytenr disk_num_bytes offset ram_bytes order.
> 
> I know with structures, there is really no need to keep any order
> between the member assignment, but with fixed ordering, it would be
> better in the long run.

I agree this pays of in the long run. The most prominent example is
ordering of the btrfs_key initialization, if it's always
objectid/type/offset it's does not slow down reading, it's enough to
read the values. Admittedly for the extent_map it's not the same because
there are more members. The important thing is to keep the same order
everywhere.