On Fri, Sep 02, 2022 at 10:56:40AM +0900, Damien Le Moal wrote: > > - /* Max size to emit ZONE_APPEND write command */ > > + /* Constraints for ZONE_APPEND commands: */ > > + struct queue_limits limits; > > u64 max_zone_append_size; > > Can't we get rid of this one and have the code directly use > fs_info->limits.max_zone_append_sectors through a little helper doing a > conversion to bytes (a 9 bit shift) ? Well, the helper would be a little more complicated, doing three different shifts, a max3 and and ALIGN_DOWN. That's why I thought I'd rather cache the value then recalculating it on every write. But either way would be entirely feasible. > This does: > > t->max_zone_append_sectors = min(t->max_zone_append_sectors, > b->max_zone_append_sectors); > > So if we are mixing zoned and non-zoned devices in a multi-dev volume, > we'll end up with max_zone_append_sectors being 0. The previous code > prevented that. > > Note that I am not sure if it is allowed to mix zoned and non-zoned drives > in the same volume. Given that we have a fake zone emulation for non-zoned > drives with zoned btrfs, I do not see why it would not work. But I may be > wrong. Yes, this could be problematic. I wonder if we need to initialize max_zone_append_sectors to max_hw_sectors by default and use a separate flag if it is actually supported in the block layer if we want to support that.
