On 2/6/24 02:51, Bart Van Assche wrote: > On 2/4/24 04:42, Hannes Reinecke wrote: >> On 2/2/24 15:31, Damien Le Moal wrote: >>> With this mechanism, the amount of memory used per block device for zone >>> write plugs is roughly reduced by a factor of 4. E.g. for a 28 TB SMR >>> hard disk, memory usage is reduce to about 1.6 MB. >>> >> Hmm. Wouldn't it sufficient to tie the number of available plugs to the >> number of open zones? Of course that doesn't help for drives not reporting that, but otherwise? > > I have the same question. I think the number of zoned opened by filesystems > like BTRFS and F2FS is much smaller than the total number of zoned supported > by zoned drives. I am not sure what Hannes meant, nor what you mean either. The array of struct blk_zone_wplug for the disk is sized for the total number of zones of the drive. The reason for that is that we want to retain the wp_offset value for all zones, even if they are not being written. Otherwise, everytime we start writing a zone, we would need to do a report zones to be able to emulate zone append operations if the drive requested that. Once the user/FS starts writing to a zone, we allocate a struct blk_zone_active_wplug (64 B) from a mempool that is sized according to the drive maximum number of active zones or maximum number of open zones. The mempool ensure minimal overhead for that allocation, far less than what a report zone command would cost us in lost time (we are talking about 1ms at least on SMR drives). Also, with SMR, report zones cause a cache flush, so this command can be very slow and we *really* want to avoid it in the hot path. So yes, it is somewhat a large amount of memory (16 B per zone), but even with a super large 28 TB SMR drive, that is still a reasonnable 1.6 MB. But I am of course open to suggestions to optimize this further. > > Thanks, > > Bart. > > -- Damien Le Moal Western Digital Research
